Server not accepting connections after too many client connections

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

Server not accepting connections after too many client connections

Neeraj Rajgure
Hi,

I am running the "UDP: DTLS Echo Server and Client" from http://sctp.fh-muenster.de/dtls-samples.html
The only difference is my code uses pre-shared key.

The issue I am facing is after the server accepting couple of hundred connections (to few hundred
depending on timeouts set) the server stops accepting anymore connects (which I think
is fine) but it continues to be in that state even if all the old connections get closed. The client prints out
messages "SSL_connect: Resource temporarily unavailable".

We plan to use DTLS in our code so I was trying to figure out how scalable or what could be the upper
bound on number of active connections? To test this I am forking 2000 client processes where each
process attempt (almost at the same time) to make connection to the server.

Has anyone attempted to find out the upper limit for maximum open/active DTLS connections?

I was not able to find if this is a known issue. Is anyone aware of it?

----
I tried to debug this issue a bit to see what exactly was happening.

It seems to me the server gets into an infinite loop:

again:
        i = dtls1_get_message_fragment(s, st1, stn, max, ok);
        if ( i == DTLS1_HM_BAD_FRAGMENT ||
                i == DTLS1_HM_FRAGMENT_RETRY)  /* bad fragment received */
                goto again;

File: openssl-1.0.0a/ssl/d1_both.c

Function: dtls1_get_message

The function dtls1_get_message_fragment( ) always returns DTLS1_HM_FRAGMENT_RETRY. The reason
I could see was "s->d1->handshake_read_seq" does not match the incoming message's seq number
i.e. "msg_hdr.seq".
This happens when the server sends "Hello Verify Request" to one of the clients that is attempting to
connect; after that the server starts expect the next message's seq number (msg_hdr.seq) to be 1. In my
scenario either the server was too late to respond back with the HelloVerify or the client just died. But the
servers is still expecting the response to its HelloVerify from that particular client and keeps discarding
any further incoming handshake messages in the above loop.

----

Thanks,
Neeraj Rajgure