On 06/04/18 00:19, Varun Kulkarni wrote: > > > On Thu, Apr 5, 2018 at 4:03 PM, Matt Caswell <matt@xxxxxxxxxxx > <mailto:matt@xxxxxxxxxxx>> wrote: > > > > On 05/04/18 23:37, Varun Kulkarni wrote: > > > > > Thanks for the reply Matt. Previosuly , I did the exact thing you > > mentioned. But in that case , the DTLSV1_listen returns succesfully (> > > 0) immediately on reception of > > app packet and hangs on SSL_accept. > > > > Here is tshark trace of the same: > > > > 1 0.000000000 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello > > 2 0.000136330 127.0.0.1 → 127.0.0.1 DTLSv1.0 90 Hello Verify > > Request > > 3 0.000258998 127.0.0.1 → 127.0.0.1 DTLSv1.0 264 Client Hello > > 4 0.999217798 127.0.0.1 → 127.0.0.1 DTLSv1.0 264 Client Hello > > 5 1.001095034 127.0.0.1 → 127.0.0.1 DTLSv1.0 1482 Server > > Hello, Certificate, Server Key Exchange, Certificate Request, Server > > Hello Done > > 6 1.003771485 127.0.0.1 → 127.0.0.1 DTLSv1.0 1457 Certificate, > > Client Key Exchange, Certificate Verify, Change Cipher Spec, Encrypted > > Handshake Message > > 7 1.004282757 127.0.0.1 → 127.0.0.1 DTLSv1.0 1252 New Session > > Ticket, Change Cipher Spec, Encrypted Handshake Message > > 8 4.313854533 127.0.0.1 → 127.0.0.1 DTLSv1.0 103 Application Data > > 9 4.314110117 127.0.0.1 → 127.0.0.1 DTLSv1.0 295 Application > > Data > > * 10 31.662557986 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello* > > 11 32.662344551 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello > > 12 34.665481449 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello > > 13 38.662321433 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello > > 14 46.662998247 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello > > 15 62.662816876 127.0.0.1 → 127.0.0.1 SSL 244 Client Hello > > > > The trace starting from 10 is from the second client and it hangs > > because DTLSv1_listen has already returned and is struck on SSL_accept. > > > > Can you clarify that at any moment of time, dtls can process only one > > handshake at a time. > > For any single thread that is true. It is self evident that in a single > thread you can only do one thing at a time. But plenty of applications > still manage to handle multiple simultaneous clients! There are two > general ways that applications solve this problem. > > 1) Have one thread for DTLSv1_listen. When a client connects offload the > SSL_accept call to some other thread. In the first thread you can loop > around and call DTLSv1_listen again while, at the same time, the second > thread can process the handshake with the connected client. > > > This is what I tried to do. But it appears that DTLSV1_listen() fails > to send > the Hello verify request for the second client (Refer trace above). But > If I recreate the fd > every time in the thread, it works as expected. This code is quite old now and some things have moved on a bit in terms of the OpenSSL API, but take a look at the sample code here: https://web.archive.org/web/20150806185102/http://sctp.fh-muenster.de:80/dtls/dtls_udp_echo.c This might give you some hints about how to tackle the problem. Matt > > or > > 2) Interleave processing of different clients and DTLSv1_listen within > the same thread. Usually on some event driven process (e.g. select, > poll, epoll, libevent etc). So in this case you set the underlying fd to > be non-blocking and then handle the > SSL_ERROR_WANT_READ/SSL_ERROR_WANT_WRITE errors than you get back from > OpenSSL (see man page for SSL_get_error). > > Matt > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > <https://mta.openssl.org/mailman/listinfo/openssl-users> > > > > > -- > > > Regards, > Varun K S > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
