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. 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
