Socket.io: Tambahkan dukungan wildcard untuk acara

sepakat.

AcaraEmitter2

+1
Ini akan memungkinkan kita untuk membuat filter dan apa yang tidak untuk semua acara.

• ketergantungan lain
• harus tercermin di sisi klien (kode?)
• haruskah catchall dipanggil sebelum acara tertentu? atau dalam urutan definisi? klarifikasi diperlukan
• hanya perilaku sinkronisasi -- bukankah lebih baik memperkenalkan filter _async_ khusus untuk acara?

+1

hanya perilaku sinkronisasi -- bukankah lebih baik memperkenalkan filter asinkron khusus untuk acara?
@dvv

Saya cukup tertarik dengan ide ini.

beberapa pilihan EE2 bukanlah yang saya anggap ideal tetapi saya memberi +1 pada gagasan umum tentang ini, meskipun hanya "*" yang didukung

benar-benar catchall: manager.on("event", function(client, event, data) {} -- juga akan memungkinkan untuk mengurangi jumlah penutupan

saya tidak ingat penolakan apa pun untuk hanya menambahkan pendengar catchall, satu-satunya perdebatan yang saya ingat adalah apakah kita menggunakan "*" atau tidak atau jika kita menggunakan nama metode lain seperti .addGlobalListener()

+1
Saya juga membutuhkan cara untuk mencegat semua acara, dan meminta pawang khusus untuk melihatnya, hanya setelah saya selesai memprosesnya. Sebagian besar untuk tujuan logging akan ini diperlukan. Socket.io logger saat ini hanya masuk ke konsol, dan dengan cara yang sangat benar.
pendekatan dvv -s benar-benar sesuai dengan keinginan saya.
Bahkan mungkin ide yang baik untuk meminta kami menyampaikan acara tersebut ke penangan tertentu, dan kami hanya mendapatkan semua acara, seperti yang dijelaskan oleh dvv.

Tolong selesaikan masalah ini :)
Akan senang melihat fitur ini diimplementasikan.

Baiklah, saya baru saja menambahkan EE2 ke cabang di garpu saya: https://github.com/einaros/socket.io/commit/2107ff00f3ddf2d781d3e3c3b7dfb1fc990f7ec5

Cabangnya ada di: https://github.com/einaros/socket.io/commits/ee2

Pikiran sangat disambut.

jika EE2 menghilangkan nama metode yang aneh dan menambahkan .on('*') saya akan memberi +1 itu

Saya -1 di EE2

Itu menambahkan lebih banyak ke kode, kami juga perlu mendukungnya di sisi klien. Yang berarti kita harus mengirimkan perpustakaan tambahan 11,8 KB (diperkecil ~3.5kb). Tetapi dengan pasar seluler yang akan datang, saya ingin menghemat byte sebanyak mungkin.

Jika ini benar-benar hanya tentang memiliki wildcard / catch all listener.. Maka ini harus dilakukan dengan mengganti fungsi emit yang ada yang hanya melakukan satu panggilan tambahan ke pendengar all . Ini akan seperti perubahan 3 - 5 LOC (tidak termasuk komentar ;)). Dan harus disembunyikan di balik kunci preferensi karena memengaruhi kinerja. EventEmitting adalah jalur kode panas dan harus selalu seoptimal dan secepat mungkin. Menambahkan wildcard akan menurunkan kinerja.

catch-all jelas merupakan bagian yang lebih penting, cukup mudah untuk mengaktifkan acara setelah itu jika perlu

Tidak terlalu peduli dengan wildcard, atau EE2, tetapi cara, untuk mencegat semua acara adalah suatu keharusan.

jika EE2 ... menambahkan .on('*') saya akan memberi +1 itu

TJ kamu gila bro...

server.on('foo.*', function(value1, value2) {
  console.log(this.event, value1, value2);
});

Itu dari README EE2. Secara alami, "foo." adalah opsional.

jika EE2 menghilangkan nama metode yang aneh

Saya setuju.

@pyrotechnick EE2 .on('*') merupakan iirc yang mudah didapat

* bukan catch-all dalam arti ia menangkap semua event secara membabi buta tetapi ia secara efektif menangkap semua event karena pola * cocok dengan semua saluran.

Ini tidak efisien; tapi itu bekerja seperti yang diharapkan.

saya salah. Kamu benar...

{EventEmitter2} = require 'eventemitter2'

emitter = new EventEmitter2 wildcard: on

emitter.on '*', ->
  console.log <strong i="6">@event</strong>, arguments...

emitter.emit 'foo'
emitter.emit 'foo.bar'

isabel:hydrogen pyrotechnick$ coffee test.coffee 
foo

Saya hampir lebih suka perilaku ini ketika datang ke wildcard.

Ketika saya memikirkan semua kejadian wildcard/"namespace" ini, itu membuat saya sedih; JavaScript sudah memiliki cara yang luar biasa untuk mencocokkan pola -- mereka tinggal di // atau dibuat dengan RegExp . Apakah ini terlalu lambat?

Bisakah saya memberi +1 pada pentingnya ini lagi. Saya ingin melihat ini dalam rilis mendatang.

Seseorang memposting solusi di sini: http://stackoverflow.com/questions/8832414/overriding-socket-ios-emit-and-on/8838225

Itu tidak berhasil karena saya masih tidak dapat terhubung ke acara tersebut. Dalam aplikasi saya, server tidak mengetahui nama ruangan dari klien. Jadi saya ingin dapat menanggapi semua pesan untuk ruangan mana pun dan idealnya mengetahui nama ruangan tempat pesan itu dikirim.

Tambahkan dukungan ekspresi reguler untuk acara.. dengan cara ini, rentang kata kerja dan kata benda dapat ditangkap.

+1

+1

+1

+1

+1

Saya akan menyukai metode super global yang menangani semuanya

io.set('global_listener', function(namespace, event, args, emit){
// lakukan sesuatu berdasarkan event dan argumen namespace
// Saya bisa atau tidak memanggil emit() untuk memanggil event listener yang terhubung dengan namespace dan event itu
});

io.set('global_authorization', function(namespace, handshakeData, callback){
// berdasarkan namespace dan handshakeData menerima atau tidak koneksi
});

Saya membutuhkan emitor yang mendukung catch-alls a. la. socket.on("*") , bekerja pada klien, dan masih ringan. Jadi saya mengambil emitor @visionmedia dari UI Kit dan sedikit memperpanjangnya. Mungkin akan cocok untuk ini. Jadi, untuk apa nilainya. Saya akan meninggalkan ini di sini: https://github.com/HenrikJoreteg/wildemitter

@HenrikJoreteg
Kami mungkin menambahkan '*' di luar kotak ke https://github.com/component/emitter.
Juga, emitor itu akan memberi daya pada socket.io berikutnya. Ini termasuk pintasan off ke removeListener yang bagus :D

wah!

+1

++

+1

+1

+1

+1

+=1

+1

+1

+1

+1

Apakah ada yang bekerja ke arah ini belum? Setiap jenis jejak?

Saya memiliki _sort of_ solusi yang bekerja cukup baik untuk tujuan yang kami butuhkan, tetapi ini bukan solusi wildcard penuh... lebih seperti implementasi '*'

https://github.com/Attorney-Fee/socket.io

+1

+1

+1

+1

+1

+1

Saya benci meninggalkan komentar yang tidak memberikan kontribusi apa pun yang berarti, tetapi ini telah diminta selama 2 tahun sekarang, dan segala sesuatu yang konstruktif telah dikatakan. Jadi...

+1

Ini akan cukup mudah untuk ditambahkan di userland, saya tidak melihat perlunya memilikinya di basis kode inti. Jika saya dapat membantu dengan kait apa pun untuk membuatnya lebih mudah untuk memperluas fungsionalitas emitor acara tanpa terlalu banyak menambal monyet, saya akan dengan senang hati melakukannya.

Bagaimana ini akan diterapkan di userland? Semua solusi yang saya lihat melibatkan forking basis kode, dan beberapa orang telah menautkan ke perpustakaan yang berbeda sama sekali.

Dalam kasus saya, saya hanya membutuhkan "tangkap semua dalam satu fungsi" yang sederhana dan sederhana, tetapi dukungan RegEx tampaknya tidak terlalu sulit (bagi pria yang tidak melihat sumbernya terlalu dekat), dan tentu saja akan sangat berguna . Saya menggunakan ekspresi reguler di rute Express.JS saya sepanjang waktu; akan menyenangkan untuk dapat melakukan hal yang sama di socket.io.

Lapisan / protokol transport akan tetap tidak berubah. Anda cukup mengganti 'pancarkan' di kedua ujungnya untuk tidak hanya melakukan pencarian peta tetapi pencarian yang lebih komprehensif (berbasis regexp).

Saran penerapan cepat:

• Ganti on untuk mempertahankan struktur data khusus untuk ekspresi reguler ketika '*' ditemukan dalam nama acara
• Ganti emit untuk terlebih dahulu melakukan kasus cepat (pencarian peta biasa), lalu buka pendengar '*' dan lihat apakah mereka cocok.

Jelas ini tidak memerlukan garpu. Yang saya maksud dengan kait adalah bahwa kita berpotensi menemukan solusi untuk tidak memerlukan patch monyet, tetapi mengingat 2 metode itu cukup sederhana, saya tidak menganggap itu masalah besar.

Hanya karena penasaran, tidak bisakah kita mengganti socket.Manager.prototype.onClientMessage dari userland?

Saya melakukannya dan bekerja dengan baik, di node, tidak ada perubahan pada modul socket.io. Tidak terlalu cantik dan cenderung pecah tetapi setidaknya Anda menghindari forking.

https://Gist.github.com/lmjabreu/5714985

Tidak bisakah seseorang menambahkan process.EventEmitter = require('eventemitter2').EventEmitter2 suatu tempat sebelum socket.io diperlukan? Ini sepertinya bekerja untuk saya ...

Membuka prototipe jelas bukan perbaikan pengguna. Saya mengerti tidak ingin menerapkan dukungan regex penuh atau apa pun selain socket.on('*') sederhana akan sangat membantu.

Tiket ini sudah berumur 2 tahun sekarang.

Apakah ada rencana untuk mengatasinya, karena ini jelas merupakan fitur yang berguna?

Jika jawabannya tidak, saya ingin garpu dan menambahkannya sendiri.
Tetapi saya lebih suka melakukan ini hanya jika kemungkinan akan digabungkan kembali.

Adakah devs yang bisa menjawab ini?

Setuju dengan hampir semua komentar, hal-hal mewah bisa lebih atau kurang bisa diperdebatkan, tetapi menangkap semua akan menyenangkan. Pengguna dapat melakukannya sendiri, tetapi prosedur yang telah ditentukan akan lebih bersih.

Sayang ini tidak ada.

Itu memang ada, lihat tautan yang diposting seseorang sebelumnya
http://stackoverflow.com/questions/8832414/overriding-socket-ios-emit-and-on/8838225

Saya menggunakan ini, dan itu berfungsi dengan baik :)

+1

Apakah monyet menambal untuk sesuatu yang sederhana seperti itu tampaknya, bagi saya, sesuatu seperti praktik yang buruk, namun, saya pikir tidak ada implementasi besar yang harus digunakan, sesuatu yang sederhana seperti Backbone.Events akan cukup untuk sebagian besar pengembang dalam masalah ini, Menurut saya. (walaupun Backbone tidak menggunakan "*", tetapi "semua" untuk acara global, meneruskan nama acara yang awalnya disebut, yang merupakan hal terbaik untuk dilakukan). (itu hanya saran, namun) =)

Secara pribadi +1 ke cara RegExp, rasanya lebih Javascript dan lebih sedikit konsol jika dibandingkan dengan wildcard "*" .

Tapi seperti suara-suara terbaru, fungsi catch-all tampaknya lebih cocok.

Tidak yakin apakah ini benar-benar masalah socket.io.

API beku untuk menyalahkan IMO.

:+1:

Jika ada yang membaca utas ini dan masih mencari cara untuk menggunakan acara wildcard di 0.9.x dan 1.0.0: https://www.npmjs.org/package/socketio-wildcard

Luar biasa @geoah !

@guille hehe, itu bukan milikku, aku baru saja menemukannya. terima kasih untuk semua kerja keras Anda btw ^_^

Menyiapkan middleware untuk socket.io tadi malam.

https://www.npmjs.org/package/socket.io-events

+1
Akan menyenangkan untuk memotong biaya pembuatan pendengar baru ketika data akan selalu ditangani dengan cara yang sama.
@geoah Terima kasih untuk middleware, melakukan apa yang saya butuhkan!

Jika middleware berfungsi dengan baik, maka socket.io harus tetap apa adanya.

Ini adalah salah satu hal yang menurut saya pribadi masuk akal sebagai bagian dari socket.io itu sendiri. Saya tidak melihat argumen untuk meninggalkannya kecuali "itu bukan cara yang dilakukan di sekitar sini", yang tidak pernah merupakan argumen yang sangat bagus.

Argumennya adalah bahwa kami mencoba untuk bekerja seperti node EventEmitter , dan node tidak memiliki ini, sehingga akan menjadi "socket.io-ism". Ada diskusi ekstensif di Node tentang menambahkannya dan itu tidak berhasil.

@chevex Meskipun ini awalnya perasaan saya juga, dukungan middleware baru membuatnya cukup mudah untuk menambahkan diri Anda sendiri. Melihat socketio-wildcard sebagai contoh, sangat mudah untuk mengimpor dan menggunakan; itu mungkin akan berakhir seperti express.js di mana ada beberapa middleware yang hampir selalu saya sertakan.

Itu adalah argumen yang jauh lebih baik. Saya kira Anda tidak ingin EventEmitter berperilaku berbeda dari node secara default. Dan @DanH42 Saya juga kira Anda benar bahwa menambahkannya dengan middleware lebih masuk akal bagi mereka yang membutuhkannya. saya tarik pernyataan saya :)

Jika hanya EventEmitter node yang mendukung wildcard di luar kotak.

:+1:

Saya melihat saya melewatkan masalah ini, saya memulai masalah baru pada acara penerusan:
https://github.com/Automattic/socket.io/issues/1715
Ini mencakup dua cara untuk menangani semua peristiwa dari socket.io 1.0 tanpa mengubah sumbernya.

Saya hanya ingin ini untuk debugging. Saya tidak memiliki wewenang untuk menambah atau memodifikasi perpustakaan di proyek kami. :menangis:

+1
Terkadang, Anda perlu mengetahui semua peristiwa yang sedang menyebar!

+1

• 1

Saya akhirnya menggunakan modul socketio-wildcard hden ; tampaknya metode yang paling transparan (dengan menggunakan middleware) dan bekerja cukup baik untuk saya. Tetapi :+1: untuk memasukkan ini ke dalam inti!

Terima kasih Matt! Saya telah kebanjiran tetapi saya berharap memiliki akhir pekan untuk membuat beberapa
perbaikan

dikirim dari iPhone saya

Pada 6 Januari 2015, pukul 08:30, Matt Fletcher [email protected] menulis:

Saya akhirnya menggunakan @NathanGRomano https://github.com/NathanGRomano 's
socketio-events https://www.npmjs.com/package/socket.io-events modul; dia
tampaknya metode yang paling transparan (dengan menggunakan middleware) dan bekerja cukup
baik untuk saya. Tetapi [image: :+1:] untuk memasukkan ini ke dalam inti!

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/Automattic/socket.io/issues/434#issuecomment -68864750.

+1

+1

++++++

+1 akan berguna untuk debugging.

Jika ini masalah seseorang yang sedang mengerjakan ini, saya ingin mencobanya. Saya perlu beberapa untuk mempelajari basis kode socket.io, dan saya mungkin akan meluangkan waktu untuk melihat implementasi lain seperti itu. Apa pendapat Anda tentang pola regex? Terlalu lambat? Tentu saja, saya tidak akan membuang waktu saya jika itu bukan sesuatu yang akan dipertimbangkan untuk digabungkan (saya tidak peduli jika implementasi saya ditolak, tetapi jika tidak ada minat mengapa repot-repot, kan?). Akankah pengelola mohon saran?

Saya menulis perpustakaan socket.io-events. Saya telah dibanjiri pekerjaan dan kebutuhan
untuk menyentuhnya lagi. Saya ingin mendukung ucapan terima kasih dengan itu

Pada hari Sabtu, 25 Juli 2015, John Manko [email protected] menulis:

Jika ini masalah seseorang yang hanya mengerjakan ini, saya ingin memberikannya
tembakan. Saya perlu beberapa untuk mempelajari basis kode socket.io, dan saya mungkin akan
luangkan waktu untuk melihat implementasi lain seperti itu. apa kamu?
pemikiran tentang pola regex? Terlalu lambat? Tentu saja, saya tidak akan menyia-nyiakan
waktu jika itu bukan sesuatu yang akan dipertimbangkan untuk digabungkan (saya tidak
peduli jika implementasi saya ditolak, tetapi jika tidak ada minat lalu mengapa
repot, kan?). Akankah pengelola mohon saran?

—
Balas email ini secara langsung atau lihat di GitHub
https://github.com/socketio/socket.io/issues/434#issuecomment -124901706.

+1

+1 masalah ini berlangsung 5 tahun. Mengapa dukungan wildcard belum ditambahkan lagi?

+1

+1

+1

+1

+666

+1

Teman-teman, serius. Semua orang menginginkan fitur ini- saya pikir mereka mendapatkannya. Mari kita semua berhenti dengan plus-one, please? Saya lebih suka mendapatkan email pembaruan ketika ada beberapa kemajuan aktual dengan masalah ini.

Yang mengatakan, itu berguna untuk mengetahui bahwa banyak orang tertarik.
Saya pikir idealnya GitHub harus memiliki sistem voting?

Sistem pemungutan suara akan bagus, tetapi sepertinya tidak akan terjadi dalam waktu dekat.

Saya kira masalahnya adalah solusinya telah diposting berkali-kali sekarang, tetapi tidak terlihat karena semua komentar +1.

Modul socketio-wildcard telah bekerja dengan baik untuk saya (diakui saya belum memperbarui ke simpul terbaru).
Akan bermanfaat jika seseorang dapat menjelaskan mengapa lib ini tidak cocok?

Ya, socketio-wildcard bekerja dengan sangat baik, tetapi masih merupakan ketergantungan ekstra yang sangat sederhana sehingga akan menyenangkan untuk diperkenalkan ke inti dan cukup akhiri seluruh utas masalah ini untuk selamanya. Juga menghilangkan ruang untuk kebingungan tentang modul eksternal mana yang terbaik untuk digunakan (seringkali diberi nama yang sama). Juga setuju bahwa akan lebih baik jika GitHub memiliki sistem pemungutan suara, jika saja ada cara kita dapat memilihnya...!

Saya mungkin bodoh, tetapi saya tidak tahu cara mengatur socketio-wildcard dengan objek klien IO. Ini harus serius, _serious_ dimasukkan dalam inti. Jika pengelola socket.io tidak ingin melakukannya, seseorang harus membayar proyek ini dan kita semua bisa pindah ke sana, karena ini konyol dan sejujurnya saya tidak percaya pada socket.io sekarang.

Saya mengerti bahwa pengelola tidak harus menerima setiap proposal, tetapi ini? Ini benar-benar membingungkan saya. Jalan untuk pergi.

@ n2liquid tidak begitu jelas bahwa ini harus menjadi inti, tetapi diskusinya disambut baik. Misalnya, tidak ada emitor peristiwa Node lain yang berperilaku seperti ini, meskipun diskusi juga dilakukan di sana.

@rauchg

tidak begitu jelas bahwa ini harus menjadi inti, tetapi diskusi ini disambut baik

Bisakah kita berdiskusi tentang ini?

Saya dapat memahami maksud Anda bahwa emitor semacam ini belum tentu umum di dunia simpul, tetapi itu tergantung pada apa yang Anda coba capai ....
Apakah ide untuk benar-benar mematuhi konvensi, atau menyediakan perpustakaan yang sangat berguna?

Tampaknya jelas bahwa banyak pengguna socket.io benar-benar tersandung tanpa fitur ini menjadi inti, dan tampaknya masuk akal bagi pengguna untuk mengharapkannya.

Atau dengan kata lain, apa argumen untuk TIDAK menyediakan fitur ini di socket.io?
Bahkan jika implementasinya tidak 'benar buku teks', itu akan menghasilkan cara standar untuk mengimplementasikan penangan 'catchall' ini di socket.io, daripada orang harus menggunakan banyak perpustakaan dan metode yang berbeda.
Mengarahkan orang ke lib pihak ketiga atau solusi hanya memecah-mecah hal, dan membuatnya lebih rapuh mencoba mempertahankan basis kode yang menggunakan socket.io

Saya lebih suka ada cara formal untuk menangani paket catchall, dan kemudian jika perlu diubah nanti, setidaknya ada prosedur migrasi yang direkomendasikan, daripada hanya membiarkannya bagi pengguna untuk menemukan rute mereka sendiri melalui hutan belantara

@rauchg Saya pikir cara yang keren untuk mengimplementasikan ini adalah memiliki fungsi socket.use(function(data,next){..}) yang menangkap semua acara di soket, dan diteruskan fungsi berikutnya() yang meneruskan kontrol dari catchall ke catchall berikutnya atau pengendali acara default .

Inilah cara saya menggunakan socket.io sekarang karena saya membutuhkan cara untuk membatasi jumlah acara yang masuk per/menit, yang saya yakini adalah kasus penggunaan yang umum. Terima kasih telah membaca 2 sen saya.

Saya paling suka solusi @Michael77 . Itu tidak menyentuh antarmuka atau implementasi emitor acara dan bahkan memungkinkan lebih banyak hal daripada yang kami minta di sini (mis. implementasi pelambatan pesan @Michael77 dan siapa yang tahu apa lagi).

Saya tahu ada fungsi middleware/penggunaan di socket.io, tetapi itu tidak dapat digunakan di perpustakaan klien, dan saya tidak yakin apakah itu melayani tujuan yang sama.

@carpii selalu ada alasan bagus untuk _not_ mendukung sesuatu: menambah kerumitan, mengurangi keakraban. Fitur ini mencentang keduanya.

Saya sangat menyukai ide socket.use , selain itu orang dapat dengan mudah mengimplementasikan ekstensi wildcard pada klien.

Terima kasih @carpii @Michael77 @n2liquid atas tanggapan Anda tentang ini btw.

@rauchg , maaf saya mengatakan hal-hal buruk tentang socket.io. Saya mengalami hari yang buruk. Terima kasih untuk proyek ini; itu mungkin tidak sempurna (belum), tetapi itu pasti sangat berguna.

Juga: https://github.com/hden/socketio-wildcard/issues/13

@n2liquid _all_ umpan balik diterima – terima kasih (dan kepada @hden untuk perbaikan cepat pada socket.io-wildcard ).

scoketio-wildcard sepertinya solusi yang benar-benar valid. Saya mendapati diri saya juga ingin mendapatkan nama acara di panggilan balik, sehingga saya bisa membungkus pendengar soket dan menyebarkan acara melalui pembungkus, daripada langsung mengekspos soket ke seluruh aplikasi saya. Pemahaman saya adalah bahwa ini akan membutuhkan Event Emitter 2 jika saya ingin melakukan ini dengan wildcard. Apakah ini hanya sesuatu yang konyol untuk dilakukan, lebih baik mengekspos soket secara langsung? Sesuatu berdasarkan mendengarkan 'newListener' di pembungkus (tetapi tidak tahu cara memicu acara soket, hanya bagaimana cara mendaftarkan acara soket berdasarkan fungsi panggilan yang mendaftarkan acara baru di pembungkus)? Adakah orang lain yang tertarik untuk dapat mengakses nama acara dalam panggilan balik?

@akotlar Nama acara tersedia di panggilan balik jika Anda menggunakan scoketio-wildcard.

Terima kasih! Mungkin berguna untuk menentukan ini di readme socket.io-wildcard.

bagaimana hal itu terjadi?
+1 untuk on("*", function () { untuk klien dan server

+1 sepanjang jalan

@alexey-sh @emin93 Jika Anda https://github.com/hden/socketio-wildcard , ya itu mungkin dilakukan untuk klien dan server.

@hden Terima kasih dan ya saya melihatnya dan saya sudah menggunakannya. Tapi itu ketergantungan ekstra dan tidak ada yang menentang mengintegrasikannya langsung ke inti Socket.IO, itu sebabnya ia mendapat +1 dari saya.

Itu dapat ditangani dalam logika aplikasi menggunakan satu nama peristiwa untuk semua peristiwa:

socket.emit('public-event', {'type': 'login', ...});
socket.emit('public-event', {'type': 'logout', ...});

+1 meskipun masalah sudah ditutup.

+💯 bang!

+1 !!!!

Silakan gunakan socket.use .

Apakah ada cara untuk menghubungkan ke mekanisme PING/PONG engine.io menggunakan socket.use() ?

Saya mengalami masalah di mana banyak pengguna kehilangan koneksi, dan meskipun masuk secara ekstensif di server, itu hanya mengatakan bahwa mereka terputus karena Ping Timeout.

Saya ingin mencatat paket PING/PONG, tetapi tampaknya socket.use() hanya dapat menghubungkan ke pesan acara pengguna tingkat tinggi, dan bukan protokol yang mendasari engine.io

+1

+1

+1 sejak 2011? Mereka tidak melakukannya. :(

Sekali lagi, socket.use telah ditambahkan dalam hal ini: https://socket.io/docs/server-api/#socket -use-fn

@darrachequesne Saya tidak melihat bagaimana metode di sisi server membantu dengan permintaan ini (yang untuk klien).

Ada lagi tentang ini? Karena socket.use hanya untuk server, mengapa tiket ini ditutup?

Saya tidak mengerti socket.use . Bagaimana cara mengganti?

// Server
io.in('room1').emit('backend', data_out);
io.in('room1').emit('frontend', data_out);

dengan sesuatu seperti

// Server
io.in('room1').emit('*end', data_out);  // not working code - proper regex would be nice

atau

// Client
socket.on('*end', function(data){  // not working code - proper regex would be nice

Menemukan solusi kecil - daftar semua kemungkinan:

// Client
var lala = function(data){ 
    // example
}
socket.on('backend', lala);
socket.on('frontend', lala);