On Thu, Apr 5, 2018 at 4:03 PM, Matt Caswell <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.
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
Regards,
Varun K S
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
