Our application communicates on multiple namespaces. I'm looking to join multiple namespaces and emit events to the correct namespace.
Connect to all the namespaces after socket.connect() - i.e
...
self.socket.connect()
self.socket.joinNamespace("/a")
self.socket.joinNamespace("/b")
self.socket.joinNamespace("/c")
...
鈽濓笍 This hasn't worked for me.
Connect to the require namespace before emitting an event - i.e
func emitEvent(eventName: String, namespace: String) {
socket.joinNamespace(namespace)
socket.emit(eventName, with: [:])
socket.on(eventName, callback: { (data, ack) in
//handle the data received
})
}
Each time I emit an event, I join the required namespace - is this the correct way to handle multiple namespaces in the iOS socket client?
When using the 2nd approach, I'm getting LOG SocketParser: Got invalid packet: SocketPacket for an event that is emitted on a different namespace than other emitted events. According to SocketParsable.swift I would assume that the error is due to not being on the same namespace that I've subsequently joined (we emit multiple events in different namespaces throughout the app)
What is the correct approach to join (and listen) to messages on multiple namespaces?
Client version: 11.1.3
Joining multiple namespaces isn't supported. You will need multiple sockets for each namespace.
I've attemped this in https://github.com/Superbalist/socket.io-client-swift/commit/bbf5367844beccd795209e83b0c466a40e4923db and seems to be working in our implementation of socket.io.
We're currently using v11.1.3 - I'll submit a PR for the current version once we upgrade.
Comments/suggestions welcome
My only concern is that it will be too different from the reference implementation, but if it works that would be nice. Honestly I haven't looked into the JS version and how it actually does namespaces behind the scenes. I vaguely remember it has a higher abstraction called a manager that this library lacks.
I need to update the readme, but to develop on the latest version you'll need to do carthage update
I'll do more reading on how other clients deal with this and try bring a future PR in line with those where possible
I think adding a manager might be a bit more work, since it might require restructuring the client in a few places. I would have to see how it's implemented before I make a decision if it's a good thing to add now.
So @alihen, looking at the js client. Each individual client can only connect to a single namespace. https://github.com/socketio/socket.io-client/blob/master/lib/socket.js#L220. What this library lacks, and what I'm working on adding now is a "Manager" that will allow multiple clients to share a single Engine. Currently they must all have separate engines.
Although this is going to be a pretty drastic change to how things work currently... so I'm not sure if it's worth it.
@alihen You can check out #844. It'll be a somewhat radical change in the API that'll require adding a fair bit of documentation so people can update their code for compatibility.
Check my answer in #236
Most helpful comment
So @alihen, looking at the js client. Each individual client can only connect to a single namespace. https://github.com/socketio/socket.io-client/blob/master/lib/socket.js#L220. What this library lacks, and what I'm working on adding now is a "Manager" that will allow multiple clients to share a single Engine. Currently they must all have separate engines.