Spring-RSocket: potential server file descriptors exhaustion with idle connections

[mostroverkhov]

Spring-RSocket server accepts idle connections that never send anything, then stay forever because initial frame is not received
and server seemingly lacks timeout for handshake.

Bad clients may open arbitrary number of idle connections that exhaust server's available file descriptors, make It unable to accept further connections.

With reproducer on 2.5.4 client opens 10k idle connections that are never timed out by server.

./server.sh , idle_connections.sh

[philwebb]

I think this is something that the Spring Framework team will need to investigate. I’ll transfer the issue.

[rstoyanchev]

Thanks for the report. For STOMP over WebSocket we have a timeToFirstMessage property that sets the max time to wait for the first STOMP frame (CONNECT) after the connection is established.

A DuplexConnectionInterceptor would probably gives us the ability to do something similar for RSocket although such an interceptor would have to be installed. This could be done in Boot, but it does mean that other Java applications that are not using Boot or that not using Spring would still have the issue.

I think we should investigate for this to be done in RSocket Java as a built-in feature.

/cc @OlegDokuka

[OlegDokuka]

Observed same in the new version of rsocket-ts. Thus, I guess we can expose a property on the rsocket-server side to terminate idle connections

[rstoyanchev]

I don't think I can transfer the issue across organizations, so I've created rsocket/rsocket-java#1025.

[mostroverkhov]

@rstoyanchev what about 1, 2, 3? It seems current RSocket/RSocket-java servers are not safe to expose to 3rd party clients, and I see people suggest using It even with mobile applications.