A socketIO handshake looks something like this :
http://localhost:3000/socket.io/?EIO=3&transport=polling&t=M5eHk0h
What is the t
parameter? Can't find a explanation.
This is the timestampParam
from engine.io-client. Its value is a Unique ID generated using the npm package yeast
.
This is referenced in the API docs under the Socket Constructor Options (docs below). If no value is given to timestampParam
when creating a new instance of a Socket, the parameter name is switched to t
and assigned a value from yeast()
. You can see this in the source for on Line 223 of lib/transports/polling.js
timestampParam
(String
): timestamp parameter (t
)
To clarify where engine.io-client
comes into play, it is a dependency of socket.io-client
which, socket.io
depends on. engine.io
provides the actual communication layer implementation which socket.io
is built upon. engine.io-client
is the client portion of engine.io
.
t
?As jfriend00 pointed out in the comments, t
is used for cache busting. Cache busting, is a technique that prevents the browser from serving a cached resource instead of requesting the resource.
Socket.io implements cache busting with a timestamp parameter in the query string. If you assign timestampParam
a value of ts
then the key for the timestamp would be ts
, it defaults to t
if no value is assigned. By assigning this parameter a unique value created with yeast
on every poll to the server, Socket.io is able to always retrieve the latest data from the server and circumvent the cache. Since polling transports would not work as expected without cache busting, timestamping is enabled by default and must be explicitly disabled.
AFAIK, the Socket.io server does not utilize the timestamp parameter for anything other than cache busting.
More aboutyeast()
yeast()
guarantees a compressed unique ID specifically for cache busting. The README gives us some more detailed information on how yeast()
works.
Yeast is a unique id generator. It has been primarily designed to generate a unique id which can be used for cache busting. A common practice for this is to use a timestamp, but there are couple of downsides when using timestamps.
- The timestamp is already 13 chars long. This might not matter for 1 request but if you make hundreds of them this quickly adds up in bandwidth and processing time.
- It's not unique enough. If you generate two stamps right after each other, they would be identical because the timing accuracy is limited to milliseconds.
Yeast solves both of these issues by:
- Compressing the generated timestamp using a custom
encode()
function that returns a string representation of the number.- Seeding the id in case of collision (when the id is identical to the previous one).
To keep the strings unique it will use the
.
char to separate the generated stamp from the seed.