Can anyone explain to me about "volatile" message in socket.io/nodejs?

Question

In new socket.io v0.7, there's a new feature "volatile message".

In "how to use", they write like that:(at http://socket.io/#how-to-use)

Sending volatile messages.

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.

As I think volatile is something like inconsistent so why they told that we should use volatile message for the type of message we mustn't missed? What about default messages? What must I do to be sure the message will arrive to client?

Beside, I also want to ask about xhr-multipart transport. I don't see it in list of transport in v0.7. Was it removed?

Answer 1

Like it says normally socket.io keeps track of the messages it receives and if I a user has missed a message it will be sent again. If you don't want this overhead(extra work) you can use volatile message at the expense, that the user can miss a message. If you also want to have messages received in order you can use acknowledgements(callback) =>

server:

var io = require('socket.io').listen(80);

io.sockets.on('connection', function (socket) {
  socket.on('ferret', function (name, fn) {
    fn('woot');
  });
});

client:

<script>
  var socket = io.connect(); // TIP: .connect with no args does auto-discovery
  socket.on('connection', function () {
    socket.emit('ferret', 'tobi', function (data) {
      console.log(data); // data will be 'woot'
    });
  });
</script>

I also can't find xhr-multipart, but I guess if you really want to know you could ask Guille?

Answer 2

It is highly unlikely that messages will come out of order or be missed given that sockets are by nature persistent connections and reliability of order is all but guaranteed, but it is technically possible. Volatile messages aren't inconsistent but can be discarded which means that when discard they can be received out of order.

Socket.io - Volatile Events

According to the Socket.io documentation messages will be discarded in the case that the client is not connected.

// server-side
io.on("connection", (socket) => {
  console.log("connect");

  socket.on("ping", (count) => {
    console.log(count);
  });
});

// client-side
let count = 0;
setInterval(() => {
  socket.volatile.emit("ping", ++count);
}, 1000);

If you restart the server, you will see in the console:

connect
1
2
3
4
# the server is restarted, the client automatically reconnects
connect
9
10
11

Without the volatile flag, you would see:

connect
1
2
3
4
# the server is restarted, the client automatically reconnects and sends its 
buffered events
connect
5
6
7
8
9
10
11

Note: The documentation explicitly states that this will happen during a server restart, meaning that your connection to the client likely has to be lost in order for the volatile emits to be dropped.

In order to insure clients arrive to the client your best bet is to use the standard emit types and check the socket for connection when sending a messages.

if (this.socket.connected) {
  doSomething...
  this.socket.emit('some_event',{})
}

This should in theory give you a minimum amount of confidence that the socket is ready to receive messages.

Socket.io - Acknowledgements

You can also try acknowledgements which send responses to various emits upon receipt and then you can handle that somehow, probably sending another message if an acknowledgement hasn't be received in a certain amount of time. You'd probably want to create some sort of message queue to manage this.

Hope this helps anyone who hits this topic.