Is there any good solution to support long polling clients in scenarios like this:
sockets.in("room1").volatile.emit(message);
sockets.in("room2").volatile.emit(message);
The client is in both rooms and is only received the message in one of the rooms. I suppose it has to do with long polling. When I remove “volatile” from the latter emit, then it works – but is there another way?
Side question: Are there any side-effects by not using VOLATILE? Like the server throwing exceptions etc. I can imagine that it comes with abit of overhead. And how many resends does the server perform?
Best regards,
Mattias
Actually volatile is more unstable. If polling have not reached server after last data sent, it’s gone. You don’t need to use volatile. If you do not use it, it will queue up all emit in case of connection has not reached yet and when it reach, it get executed in order. I cannot see any advantage from using volatile from my experience.
Text from Socket.io first page about volatile:
“Sometimes certain messages can be dropped. Let’s say you have an app that shows realtime tweets for the keyword bieber.
If a certain client is not ready to receive messages (because of network slowness or other issues, or because he’s connected through long polling and is in the middle of a request-response cycle), if he doesn’t receive ALL the tweets related to bieber your application won’t suffer.
In that case, you might want to send those messages as volatile messages.”