Socket.io: Socket.io putuskan dengan batas waktu ping secara acak

Sudahkah Anda mencoba mendengarkan peristiwa kesalahan yang dipancarkan?
Berikut adalah artikel stack overflow yang berisi daftar kejadian umum yang dipancarkan oleh socket..

http://stackoverflow.com/questions/24224287/list-of-socket-io-events

Saya memiliki masalah yang sama apakah Anda mengetahuinya?

@jitendrapawar apakah Anda dapat mereproduksi secara konsisten?

Tidak, itu tidak berulang kali, itu terputus secara acak dengan ping
waktu habis.

Pada 10 Jan 2017 19:50, "Damien Arrachequesne" [email protected]
menulis:

@jitendrapawar https://github.com/jitendrapawar bisa
mereproduksi secara konsisten?

—
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub
https://github.com/socketio/socket.io/issues/2769#issuecomment-271586816 ,
atau matikan utasnya
https://github.com/notifications/unsubscribe-auth/ANP7JpiqxkTpZlc5CsayjIZf9GAqURLiks5rQ5OsgaJpZM4K9hrg
.

• Apakah Anda mengirim data biner? (https://github.com/socketio/socket.io/issues/2666)
• Apakah batas waktu setelah penundaan tertentu (bisa terkait proxy)?
• Apakah ini terkait dengan browser tertentu?
• Apakah mereka terhubung kembali dengan benar setelah batas waktu ping?

Masalah yang sama di sini. Tidak ada kesalahan lain yang dipancarkan. Tampaknya benar-benar acak.

Saya menonaktifkan jaringan, dan segera mengaktifkannya. Sekitar 1 menit kemudian, server mendapat masalah 'ping timeout'.

  pingInterval: 25000,
  pingTimeout: 60000,

penulis mengatakan bahwa: a client may have to wait up to pingTimeout + pingInterval ms before getting a disconnect event.
tetapi saya menemukan ketika saya F5 halaman web, saya akan mendapatkan socket.id , apakah saya terputus ????saya menyegarkan halaman saya kurang dari 1 detik,
saya tidak dapat menemukan ini cara bekerja

Saya juga baru saja menemukan masalah ini. Aplikasi kami telah berjalan dengan baik tanpa pemutusan ini selama lebih dari setahun, tetapi sekarang mengalami pemutusan acak. Dalam debug, alasan pemutusan adalah "ping timeout" dan klien tampaknya tidak memiliki masalah untuk menyambung kembali.

Satu-satunya hal yang dapat saya persempit sejauh ini adalah versi baru Google Chrome. Chrome 63 tampaknya tidak memiliki masalah, tetapi pengguna di 64 adalah yang mengalami pemutusan dan saya tidak tahu mengapa

Saya menghadapi masalah yang sama persis dan saya menggunakan Chrome 63 @jstelz. Apakah ada yang menemukan masalah atau solusi?

Itu mungkin ditautkan ke https://github.com/socketio/engine.io/issues/312#issuecomment -274367814.

@darrachequesne Dalam kasus saya ini pasti terkait dengan masalah pengatur waktu sisi klien yang
Saya melihat gejala yang sama seperti yang disebutkan di atas oleh yang lain dan sangat mudah untuk direproduksi. Saya hanya perlu memulai aplikasi web saya, pastikan itu terhubung, dan buka tab lain untuk memaksa aplikasi saya berjalan di latar belakang. Akhirnya penghitung waktu akan dibatasi oleh chrome yang mengakibatkan batas waktu ping, yang pada akhirnya akan membuat server memutuskan aplikasi saya karena menganggap aplikasi tidak hidup lagi.
Ada satu cara yang mungkin untuk menonaktifkan pelambatan ini di chrome => https://www.tenforums.com/tutorials/80233-enable-disable-google-chrome-background-tab-throttling-windows.html
Tapi ini tidak sempurna dan kadang-kadang bahkan tidak berlaku. Mungkin satu-satunya solusi yang baik adalah apa yang juga dilakukan di primus lib: untuk Membalikkan arah pesan ping/pong (https://github.com/primus/primus/pull/534)
Ini tampaknya refactoring yang agak besar di engine.io yang memengaruhi lib server dan klien ...

@sirudog yah, itu perubahan yang sangat besar! Saya pikir kita harus melakukan itu meskipun ...

Saya memiliki masalah dengan game yang sedang saya kerjakan.

Ketika saya mengatur server ke
pingInterval: 1000, pingTimeout: 500
klien saya mengirimkan setiap detik batas waktu ping dan menghubungkan kembali.

Ketika saya mengatur server ke
pingInterval: 500, pingTimeout: 1000
Saya tidak mendapatkan batas waktu tetapi server tidak pernah mendeteksi pemutusan.

Bagi siapa pun yang mengalami batas waktu acak, coba ubah engine.io default "transport upgrade timeout" (upgradeTimeout).

Setelah menyambungkan kembali dan menerima data dalam jumlah besar, soket tampak tidak responsif, debugging engine.io tidak menunjukkan kesalahan apa pun, hanya soket yang mencoba memutakhirkan transport setiap kali klien tersambung kembali.

contoh server:

// index.js
import io from 'socket.io';
import expressApp from './express/expressApp'; // express server
import socket from './socket/socket';

const port = 4000;
expressApp.set('port', process.env.Port || port);

const server = expressApp.listen(port, 'localhost');

const socketIo = io(server, {
  upgradeTimeout: 30000 // default value is 10000ms, try changing it to 20k or more
});

socket(socketIo);

// socket.js
export default socketIo =>
  socketIo.on('connection', socket => {
  //...return large amount of data
  }
}

Anda dapat membaca lebih lanjut tentang engine.io di sini:
https://github.com/socketio/engine.io

Hai

Bagi siapa pun yang mengalami batas waktu acak, coba ubah engine.io default "transport upgrade timeout" (upgradeTimeout).

Setelah menyambungkan kembali dan menerima data dalam jumlah besar, soket tampak tidak responsif, debugging engine.io tidak menunjukkan kesalahan apa pun, hanya soket yang mencoba memutakhirkan transport setiap kali klien tersambung kembali.

contoh server:

// index.js
import io from 'socket.io';
import expressApp from './express/expressApp'; // express server
import socket from './socket/socket';

const port = 4000;
expressApp.set('port', process.env.Port || port);

const server = expressApp.listen(port, 'localhost');

const socketIo = io(server, {
  upgradeTimeout: 30000 // default value is 10000ms, try changing it to 20k or more
});

socket(socketIo);

// socket.js
export default socketIo =>
  socketIo.on('connection', socket => {
  //...return large amount of data
  }
}

Anda dapat membaca lebih lanjut tentang engine.io di sini:
https://github.com/socketio/engine.io

Hai,

Saya mencobanya tetapi masih banyak yang terputus:

15:10:57,270 urbanGUI INFO terhubung
15:10:57,549 urbanGUI INFO Klien terputus: 6830bd090575426f9c53dec108702e04
15:10:59,70 urban INFO GUI terhubung
15:10:59,342 urbanGUI INFO Klien terputus: e2eb60d8a2aa445f94a17b6c6fc00e34
15:11:00,770 urbanGUI INFO terhubung
15:11:01,41 urbanGUI INFO Klien terputus: 62b2619d3b3a4c05aa9cfa0ad3df9524
15:11:02,655 urbanGUI INFO terhubung
15:11:02,940 urbanGUI INFO Klien terputus: a421da49b04c46f38c1ae8c08b14e5db
15:11:04,153 urbanGUI INFO terhubung
15:11:04,421 urbanGUI INFO Klien terputus: b935f53d393c42488411e2b6c3e5961a
15:11:05,359 urbanGUI INFO terhubung
15:11:05,630 urbanGUI INFO Klien terputus: ee8a42bb8b0e4bc8b9e813dd808c1dc3
15:11:07,232 urbanGUI INFO terhubung
15:11:07,513 urbanGUI INFO Klien terputus: 5c9804841d0a438e87536977c222c630
15:11:08,703 urbanGUI INFO terhubung
15:11:08,981 urbanGUI INFO Klien terputus: a5dfcc72eb5c4445b09fb28153220961
15:11:10.601 urbanGUI INFO terhubung
15:11:10,893 urbanGUI INFO Klien terputus: 394e409a10fa41a8aa7e7c747b4ea606
15:11:12,87 urbanGUI INFO terhubung
15:11:12,360 urbanGUI INFO Klien terputus: e83bacd1338d4306b8eaccc9597f7a0b
15:11:13,384 urbanGUI INFO terhubung
15:11:13,661 urbanGUI INFO Klien terputus: 52cf363b5d26431a8b9b6459551aedcd
15:11:14.389 urbanGUI INFO terhubung
15:11:14.664 urbanGUI INFO Klien terputus: f254c71fbd374cac9bd3d4161e53456f
15:11:15,995 urbanGUI INFO terhubung
15:11:16,275 urbanGUI INFO Klien terputus: ec7d67d7b4a04019b3496dcf40e0d41a
15:11:17,709 urbanGUI INFO terhubung
15:11:17.992 urbanGUI INFO Klien terputus: 68a9ea7e54f34cc3be9f9395b19943b7
15:11:18,720 urbanGUI INFO terhubung
15:11:19,1 urbanGUI INFO Klien terputus: e17cdcf179d9482dbf4f6befc2e0db47
15:11:19,808 urbanGUI INFO terhubung
15:11:20,91 INFO urbanGUI Klien terputus: 8f262794c9fc40bb90aa37f9fe20db80
15:11:21.430 urbanGUI INFO terhubung
15:11:21.705 urbanGUI INFO Klien terputus: 2769a86f041c422ea7806ce11177b88f
15:11:23,95 urbanGUI INFO terhubung
15:11:23,368 urbanGUI INFO Klien terputus: 3306fd1f321740e1a80d005291e1a801
15:11:24,662 urbanGUI INFO terhubung
15:11:24.943 urbanGUI INFO Klien terputus: ac6afdc9952440fc8d4846548adc50f2
15:11:25.774 urban INFO GUI terhubung
15:11:26,58 urbanGUI INFO Klien terputus: 5b270718206d49aeba597361bbff8be2
15:11:27,673 urbanGUI INFO terhubung
15:11:27,952 urbanGUI INFO Klien terputus: ce9bba31d7494d19800c24cd68aedb2c
15:11:29,477 urbanGUI INFO terhubung
15:11:29.753 urbanGUI INFO Klien terputus: a29d9cd1903c422f9606a801e4685c2c
15:11:30,684 urbanGUI INFO Klien terputus: 48924b51684e46008558c7577c1f6269
15:11:31,59 urbanGUI INFO terhubung
15:11:31.325 urbanGUI INFO Klien terputus: f2e6c04f38a94617bb6ac8a331cde224
15:11:32,858 urbanGUI INFO terhubung
15:11:33,141 urbanGUI INFO Klien terputus: 139db6786631476ea1561b669a0b2431
15:11:34.558 urbanGUI INFO terhubung
15:11:34.844 urbanGUI INFO Klien terputus: 83940d8f836e48a5918e14794e19c0c8
15:11:35,547 urbanGUI INFO terhubung
15:11:35.815 urbanGUI INFO Klien terputus: 5f85ca0cc1254b74b19d41f5c321ac8a
15:11:37,316 urbanGUI INFO terhubung
15:11:37,593 urbanGUI INFO Klien terputus: 7554f2dd4fd54bad9b95300c1b0998ca
15:11:39,195 urbanGUI INFO terhubung
15:11:39,476 urbanGUI INFO Klien terputus: 8fead9b5e8e148e9956778b7a91e875b
15:11:40,481 urbanGUI INFO terhubung
15:11:40.767 urbanGUI INFO Klien terputus: 2579464ed45b418491bda2fc60b8bcc6
15:11:41.488 urbanGUI INFO terhubung
15:11:41,761 urbanGUI INFO Klien terputus: b8b25fec44584b288d12c297b21c72bd
15:11:42,686 urbanGUI INFO terhubung
15:11:42.966 urbanGUI INFO Klien terputus: 0f780d9ebc294e47bf3f5184c38c8836
15:11:44,388 urbanGUI INFO terhubung
15:11:44.668 urbanGUI INFO Klien terputus: 14999c3f00314bb285bbde4501e3cecb
15:11:45,581 urbanGUI INFO terhubung
15:11:45.849 urbanGUI INFO Klien terputus: ada765125a374b7fbb4174d7d97bb901
15:11:47,95 urbanGUI INFO terhubung
15:11:48,328 urbanGUI INFO terhubung
15:11:48,602 urbanGUI INFO bergabung ke ruang: 6e2f8d8f-d835-478b-12a3-70ba109603a1
15:12:15,248 urbanGUI INFO terhubung
15:12:15,523 urbanGUI INFO bergabung ke ruang: 6e2f8d8f-d835-478b-12a3-70ba109603a1
15:12:41,806 urban INFO GUI terhubung
15:12:42,77 urbanGUI INFO Klien terputus: 1bfd592fe1274c4db14d37ee6e144726
15:12:43,582 urban INFO GUI terhubung
15:12:43.855 urbanGUI INFO Klien terputus: 63a0a6abdb3240f598af9e5947520362
15:12:44,988 urban INFO GUI terhubung
15:12:45,256 urbanGUI INFO Klien terputus: 930e46874fdd48888e6f2abac0e7f066

@kllr
Ubah acara pemutusan sambungan Anda untuk menunjukkan alasannya:

socket.on('disconnect', reason => {
            console.log(`reason: ${reason}`);
});

Hal lain yang dapat Anda coba adalah menjatuhkan peningkatan transportasi

const socketIo = io(server, {
  transports: ['websocket'],
  allowUpgrades: false
});

Saya mendapatkan masalah yang sama dengan socket.io 2.2. Ini secara acak mengerem setelah beberapa waktu dan mulai menyambung kembali. Kesalahannya adalah ping timeout .

Apakah ada cara untuk memastikan koneksi stabil dan tidak pernah mengerem? Myabe beberapa browser atau sesuatu seperti itu?

Hai,
Masalah yang sama di sini, saya menggunakan socket.io 2.2.0, ada yang punya solusi untuk ini?

Salam pembuka

masalah yang sama terjadi pada saya, saya di socket.io 2.2.0 , dan ketika di situs web saya ketika klien mengirim gambar di base64 ke server, dan gambarnya besar, maka ini menyebabkan klien pengirim gambar mendapatkan kesalahan batas waktu ping dan memutuskan klien. tolong beri tahu kami jika ada yang menemukan perbaikan.

Bisakah kalian mencoba dengan mengatur pingTimeout menjadi lebih tinggi dari pingInterval, seperti yang disarankan di sini:
https://github.com/socketio/socket.io/issues/3259#issuecomment -474523271

Server:

const socket = io(server, {
  pingTimeout: 30000
  // ...other props
});

Klien:

const socket = io(`${config.server}`, {
    pingTimeout: 30000
    // ...other props
  });

PingInterval default adalah 25000ms.
Jika itu masih tidak berhasil, coba hanya dengan websocket:

transports: ['websocket'],
allowUpgrades: false,
pingTimeout: 30000

Ada satu perilaku bermasalah (?) yang tidak terdokumentasi mengenai batas waktu: jika server mengirim paket besar yang membutuhkan waktu lebih lama dari interval waktu habis untuk dikirim, hal itu menyebabkan batas waktu dan pemutusan. Satu-satunya cara untuk memperbaikinya adalah memastikan Anda hanya mengirim paket yang relatif kecil. Ini adalah masalah karena itu berarti Anda harus (terlalu) memperhatikan logika server Anda sehingga data selalu dalam batas - dan - karena kecepatan koneksi adalah faktor yang tidak diketahui, sulit untuk memperbaikinya sepenuhnya.

Saya sarankan untuk menyesuaikan logika batas waktu sedikit untuk mengatasi ini.

Beberapa info lebih lanjut tentang masalah saya.
Sekarang saya mengirim paket yang lebih kecil, sekarang tidak terputus pada unggahan gambar tetapi secara acak melempar kesalahan batas waktu ping, itu terjadi secara acak sehingga sulit untuk men-debug penyebabnya sekarang karena paketnya lebih kecil.

@IIaakso apa pengaturan batas waktu ping yang disarankan, tambang ini sekarang:

js klien saya:

Pengaturan server saya:

masih menghadapi masalah yang sama pada "socket.io": "2.2.0",
"socket.io-client": "2.2.0",

socket.io- client:socket close (ping timeout) +22s

Masalah yang sama dengan @FaizanZahid . Itu hanya terputus secara acak dengan batas waktu ping ...

Masalah yang sama, dan pengaturan saya benar-benar tidak berbeda dari Anda (forceNew: true, menjadi bagian terpenting imo)

Saya memutakhirkan dari socket.io 1.x antik dengan pengaturan node 6.x ke socket.io 2.2 dan node 12.x, pada server pengiriman dan penerimaan pengujian.

Sebelum pemutakhiran, saya dapat meluncurkan sekitar 12k koneksi bersamaan dari server sumber (menjalankan klien) ke server tujuan (menjalankan server io).

Batas sistem yang jelas, batas firewall dll diperiksa dan disetel sebelum pembaruan, sehingga server "pengiriman" dan "penerima" tidak boleh menjadi penyebab masalah atau batasan.

Tetapi setelah memutakhirkan ke socket.io 2.2, saya mendapatkan batas waktu ping acak saat meluncurkan sekitar 2,5 ribu koneksi bersamaan...

*edit: tidak ada data yang dikirim di aplikasi pengujian saya, jadi ini bukan masalah panjang data, atau jenis konten. klien hanya terhubung ke server, yang melakukan auth khusus untuk klien, dan jika auth berhasil, klien menunggu acara server.

Jadi setiap wawasan tentang kemungkinan penyebabnya akan sangat dihargai;)

Dari pengujian yang saya lakukan pada pengaturan saya (FreeBSD 11.2, node 12.3.x), berikut adalah hasil yang dapat saya amati dan tiru:

versi socket.io-client | versi socket.io | hasil
2.2 | 2.2 | batas waktu ping acak setelah sekitar 2000 koneksi
1.3.5 | 2.2 | bekerja sempurna dengan 4500 koneksi bersamaan
2.2 | 1.3.5 | tidak dapat terhubung
1.3.5 | 1.3.5 | bekerja sempurna dengan 4500 koneksi bersamaan

Jadi masalahnya tampaknya ada di bagian klien dari socket-io-client 2.2, atau setidaknya 2.x cabang klien ...

Ada solusi untuk ini?? Tidak masalah dengan jumlah koneksi dalam kasus saya, itu hanya terputus secara acak setelah beberapa jam tidak aktif dengan kesalahan batas waktu ping ...

Saya memiliki masalah yang sama, apakah alasannya diketahui?

Saya memiliki masalah yang sama. Saya pikir itu masalah yang sangat aneh bagi saya.

Saya menggunakan Socket.io di React Native App saya. di IOS, itu berfungsi. Tetapi di Android, itu terputus setelah 30 ms. Berikut lognya:

  engine:ws closing +30s
  socket.io:client client close with reason ping timeout +30s
  socket.io:socket closing socket - reason ping timeout +30s
  socket.io-parser encoding packet {"type":2,"data":["disUser",0],"nsp":"/"} +30s
  socket.io-parser encoded {"type":2,"data":["disUser",0],"nsp":"/"} as 2["disUser",0] +0ms
user disconnected: dxYGo3l7Dab-1qBfAAAA
reason: ping timeout

"socket.io": "^2.2.0"
"socket.io-client": "^2.2.0"

Bagaimana saya bisa memperbaikinya di sisi Android saya?

@berksafran Saya menghadapi hal yang sama di Android saja, Bisakah Anda memberi tahu saya bagaimana Anda memperbaikinya?

Yah, Sayangnya saya tidak dapat memperbaiki masalah ini tetapi saya melihat bahwa masalah ini hanya dalam proses pengembangan. Saat Anda merilis aplikasi dan mencoba dengan react-native run-android --variant=release , server socket.io Anda akan bekerja dengan benar.

Solusi lain yang saya temukan, adalah mengunggah server socket.io Anda ke server cloud mana pun. (heroku, digitalocean, dll.) Setelah mengunggah, Anda harus mengatur alamat koneksi Anda ke url server cloud. Saya sudah mencobanya dan berhasil sekarang.

Jika ada pertanyaan, Anda dapat mengirimi saya pesan di sini.

Semoga beruntung.

Adakah yang menemukan solusinya? Diperbarui: Saya menguji setelah menerapkan aplikasi saya, itu berfungsi.

Halo semuanya,
Saya sedang mengembangkan aplikasi menggunakan socket.io.
Untuk klien saya menggunakan socket.io-client 2.3.0
Untuk server saya menggunakan socket.io versi 2.3.0

Server saya di-host di heroku. Dan saya menghadapi batas waktu ping acak ini. Batas waktu ping lebih sering terjadi saat saya membuka aplikasi di ponsel. Adakah solusi yang bisa saya coba? Terima kasih

@sukalyansen123 Dari debugging saya lama, saya perhatikan bahwa gagal untuk meng-upgrade transport dan waktu habis. Coba hanya dengan soket web:

const socketIo = io(server, {
  transports: ['websocket'],
  allowUpgrades: false
});

@sukalyansen123 - Saya memiliki masalah serupa dan bagi saya sebenarnya mengatur batas waktu default secara eksplisit tampaknya membantu.

SISI SERVER:

SEBELUM:
let io = require('socket.io')(server, { transports: ['websocket'], allowUpgrades: false });

SETELAH:
`
biarkan io = membutuhkan('socket.io')(server,
{
mengangkut: ['websocket'],
allowUpgrades: salah,
pingInterval: 25000, // default - 25000
pingWaktu habis: 60000, // default - 60000

});
`

Terima kasih. Saya mencoba melakukan ini tetapi masih tidak membantu. Sekarang lagi pada pemutusan soket ponsel terjadi, kadang-kadang karena batas waktu ping dan kadang-kadang karena transportasi dekat. Saya tidak yakin apakah ini karena penurunan koneksi internet, tetapi sekali lagi bagaimana saya harus menangani ini.

Inilah tampilan sisi klien saya jika ini membantu - saya hanya terhubung menggunakan protokol websocket
`
this.socket = io(serverURL,
{
mengangkut: ['websocket'],
AutoConnect: benar

        });

`
Semoga ini membantu

Inilah tampilan sisi klien saya jika ini membantu - saya hanya terhubung menggunakan protokol websocket
`
this.socket = io(serverURL,
{
mengangkut: ['websocket'],
AutoConnect: benar

        });

`
Semoga ini membantu

Terima kasih lagi. Juga ingin tahu bagaimana Anda menangani acara disconnect dari sisi klien.

Inilah tampilan sisi klien saya jika ini membantu - saya hanya terhubung menggunakan protokol websocket
`
this.socket = io(serverURL,
{
mengangkut: ['websocket'],
AutoConnect: benar

        });

`
Semoga ini membantu

Ini sepertinya sedikit membantu. Namun saat ini soket semakin terputus jika tetap diam untuk beberapa saat dengan penutupan transportasi. Apakah mengirim detak jantung pada interval waktu yang teratur menjadi solusi yang baik?

saya memiliki masalah yang sama. tapi saya menggunakan socket untuk game online saya.
saya menguji sesuatu dan saya menemukan ketika waktu ping habis!
alasannya adalah ketika klien (ponsel pengguna) tidur atau keluar dari permainan saya, server akan memutuskannya.
tetapi saya tidak menemukan solusi untuk memperbaikinya! belum.

Coba kode ini di sisi server

var fs = require('fs');
var pkey = fs.readFileSync('/etc/ssl/private/ssl.key'); //Replace the path of your SSL key
var pcert = fs.readFileSync('/etc/ssl/certs/ssl.crt');//Replace the path of your SSL cert
var options = {
  key: pkey,
  cert: pcert
};

var app = require('https').createServer(options);

var io = require('socket.io')(app, {'pingTimeout': 180000, 'pingInterval': 25000});

Di sini pingInterval penting, Tetap rendah, saya mencoba berbagai nilai dan menemukan 25 detik baik untuk menjaga soket terus melakukan ping sebelum kehabisan waktu. Masalah utama adalah jika dalam 60 detik tidak ada ping/pong maka akan terputus dan mencoba menyambung kembali secara otomatis. Saya juga menemukan pingTimeout di sisi server dan batas waktu dan sisi klien tidak dapat membantu memutuskan soket dalam 60 detik. Itu terjadi karena chrome versi terbaru 83.*

Seperti yang disarankan di atas , kami akan mengembalikan mekanisme ping/pong di Socket.IO v3: https://github.com/socketio/engine.io-protocol#difference -between-v3-and-v4

Saya juga mulai menghadapi masalah yang sama. Saya menggunakan versi socket.io versi 2.0.4 dan mulai menerima masalah ping timeout setelah mengimplementasikan soket dengan banyak node menggunakan socket.io-redis . Tapi itu berfungsi dengan baik dengan simpul tunggal tanpa redis. Adakah yang bisa membantu saya dengan alasan yang mungkin tentang ini?

Proyek kami baru saja memperbarui node ke v12. Setelah pembaruan itu, kami juga mendapatkan pemutusan karena batas waktu ping :| Berikut adalah daftar waktu ketika pemutusan terjadi:

11:06:59
11:08:19 +80-an
11:10:39 +140s
11:14:39 +240 detik
11:15:59 +80-an
11:20:59 +300 detik
11:22:19 +80-an
11:23:19 +60 detik
11:24:39 +80-an
11:28:59 +260 detik

Pengaturan kami:
Waktu Habis: 30 detik
Interval: 20 detik
Penundaan Koneksi Ulang: 10 detik

Hai! memiliki masalah yang sama. Socket.io versi 2.3.0 (versi yang sama pada klien dan server).
Masalah saya adalah dengan server. Setelah saya memeriksa berapa banyak yang diperlukan server untuk menyiapkan respons yang dikirim melalui soket, setelah 2 hari penggalian saya menemukan masalahnya. Itu adalah metode di mana waktu eksekusi akan meningkat secara linier, dan ketika mulai membutuhkan 1s+ untuk dieksekusi, server tidak dapat menjawab ping klien dan kemudian klien akan mengeluarkan koneksi yang ditutup dan koneksi ulang, dan dari sini Anda tahu sisanya.
Jadi, kesimpulannya, apa yang saya katakan adalah itu bukan masalah socket.io tetapi paling sering masalah server.
Semoga ini membantu.

Mencocokkan versi untuk server dan klien memecahkan masalah bagi saya. Saya sudah menguji dengan V 3.0.4 & 2.3.0