Is the server side "connection" event emitted BEFORE the client receives the connection event?

[ekr3peeK]

I am facing an issue, and I have a vague idea what is happening here, but I just want to ask, if I am correct in this:

Right now, when a connection is made on my server, I am setting listeners on the socket server side, to accept some messages from the client, the following way:

io.on('connection', serverSideSocket => {
    serverSideSocket .on('eventName1', ...);
    ....
    serverSideSocket .on('eventNameX', ...);
});

It seems to me, that sometimes my client sends a request to the connected server, BEFORE the event listeners on the server side socket are set, and thus, some messages are lost. On the client side, I have a simmilar code:

/** With setting autoconnect to false, I have access to the socket, BEFORE it attempts to connect to the server, thus I can safely set listeners on it, before even attempting to connect **/
const clientSideSocket = io(..., {
   autoconnect: false
});

clientSideSocket .on('serverEventName1', ...);
clientSideSocket .on('connect', () => {
    socket.send('eventName1', {....});   
});

What is the relation between the clientSideSocket "connect" event, and the io "connection" event? Are they firing symetrically? Because it seems to me, that they do, but if that's the case, how can I be sure, that my server is already listening on the events that the client can send? When should I add the event listeners on my server side socket?

It seems to me, that the only place I should have access to the server side socket, BEFORE the connection event on the client side is sent, are the middlewares, but it doesn't seem to be a good fit, to set these listeners on.

[darrachequesne]

The "connection" event on the server side should be fired a bit earlier, because the client waits for a CONNECT packet (received in the long-polling HTTP request, or in a WebSocket frame).

You should register the event listener in the "connection" handler, without any delay:

io.on("connection", async (socket) => {
  // BAD! "event" might be received while there is no listener
  await fetchSomething();

  socket.on("event", () => {});
});

I think autoConnect: false is not needed in your example above, because clientSideSocket.on() will always be called before the connection (which involves I/O operations).

[ekr3peeK]

okay, but then, technically, this means, that for example, if I am registering a large number of events, there is no guarantee, that the client will not receive the connect event, until the last listener is registered server side, am I right in this? the same applies for a busy server also, which may send the connect packet, and after that, start registering the event listeners?

If this is the case, isn't there a better place to attach server side event listeners, then the server side io.on('connection') callback? I was experimenting with attaching the listeners in a middleware function (and it did work, for my limited amount of tests), but it feels that that is not the correct way to go.

[ekr3peeK]

Also, what do you mean by your last sentence? If I omit setting the autoconnect to false, wouldn't the connect event fire, before going further in the code? I mean, I know (or think), that the connect event is asynchronous, and not blocking, but still, it MAY be possible, that a CONNECT packet, and also a message, is received BEFORE the on function calls run that way (albeit it having a very very small chance), or I am understanding something incorrectly?

[ekr3peeK]

oh, I think I understand what you meant originally - basically, if I am not using an asynchronous callback listener for the io.on('connection') callback, I shouldn't have problems, because of the single threaded nature of javascript, and the fact that socket.io first triggers the event, and then sends the CONNECT packet to the client.

[darrachequesne]

Yes, exactly 👍