What's the reasoning behind having a connection initialization timeout

[edwardfeng-db]

It is written here that If the client does not request a connection within the allowed timeout, the server will close the socket with the event: 4408: Connection initialisation timeout.

I'm curious about the reasoning behind this, why do we want to guard against timeout particularly for this connection_init message?

[enisdenjo]

Mainly security. If the connection is not acknowledged, the client has no business being connected to the server.

It also prevents DDoS attacks simply because if there were no timeout, you could just connect millions of clients that never connection_init and they will just stay connected on the server forever, never being kicked out, consuming resources and potentially slowing down the service.

[edwardfeng-db]

Thanks @enisdenjo. I guess I'm wondering why restrict this security check particularly to connection_init. I think there might also be cases where people have an acknowledged connection, but they never send subscribe, or after a subscription completes, the connection hangs forever.

I'm wondering what's your thoughts on, instead of adding a timeout for connection_init, adding a timeout such that a connection will be closed after x seconds of inactivity for a ws connection.

[enisdenjo]

Because connection_init can transport credentials necessary for authentication and connection_ack acknowledges them.

You might never subscribe and that is completely fine - the server shouldnt kick you out from an acknowledged connection just because you didnt subscribe...

But it most definitely should kick you out if you didnt identify yourself.

Furthermore, youre free to kick the client off whenever you want, even due to subscription inactivity, with a custom implementation using makeServer. However, that is a far off case that I wont build in.

Also note that the graphql-ws client is lazy by default; meaning, it will establish a WebSocket connection and dispose of it on demand.

[enisdenjo]

Oh and, if you were talking about adding it to the Protocol - definitely not. There is absolutely no benefit of standardizing inactivity kickoffs, just unnecessary complexity.

Such requirements are use-case specific and should be done in the userland.