[openssl-users] DTLS with multiple clients
matt at openssl.org
Thu Apr 5 23:30:06 UTC 2018
On 06/04/18 00:19, Varun Kulkarni wrote:
> On Thu, Apr 5, 2018 at 4:03 PM, Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> 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:
This might give you some hints about how to tackle the problem.
> 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).
> openssl-users mailing list
> To unsubscribe:
> Varun K S
More information about the openssl-users