DTLS in multi-thread and concurrent connection acceptance environment

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

DTLS in multi-thread and concurrent connection acceptance environment

OpenSSL - User mailing list
Hi,

OpenSSL version is 1.1.0e.

I am writing high-performance DTLS server which can accept thousands of connections concurrently.  

Originally, I decided, DTLSv1_listen would be called inside the listener thread, once DTLSv1_listen returns 1 i.e. successful, a new async socket will be created, it will be bound (using bind) and connected (using BIO_connect) with DTLSv1_listen returned address. 
This new socket will be passed to service thread, BIO_set_fd will set this fd and SSL_accept will be called from service thread to complete the remaining handshake and data exchange etc.

But behavior is not same as above, I have to call SSL_accept  after bind and connect inside the listen, where DTLS handshake is completed. If SSL_accept is not called then DTLSv1_listen is continuously called and always return 1 in listener thread. 

Could you please guide to resolve this issue or how to write multi-threaded dtls server where connection acceptance can be done inside the listener thread using DTLSv1_listen?

Thanks in Advance,
Anand


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: DTLS in multi-thread and concurrent connection acceptance environment

OpenSSL - User mailing list
Hi,


I am new in OpenSSL. 

I was confused with 1.0.2 implementation where SSL_accept is called inside the DTLSv1_Listen method. But in 1.1.0, SSL_accept must be called after DTLSv1_Listen in listener thread otherwise async socket will not be reset and epoll will always return data ready. 
Now things are working.

But I do not know, whether DTLSv1_Listen/ SSL_accept in the listener thread is capable to deal with thousands concurrent connection establishment. Is there known limitation around it? 

An alternative way, Call recvfrom from listener thread, pass the buffer and peer remote addresses to service thread, make new SSL object and Mem BIO and call  DTLSv1_Listen/ SSL_accept methods. Later use, Mem BIO and recvfrom and sendto calls for data exchange.


Could you please help me decide the better way?



Regards,
Anand Choubey



On Monday, November 27, 2017, 8:21:46 PM GMT+5:30, Anand Choubey via openssl-users <[hidden email]> wrote:


Hi,

OpenSSL version is 1.1.0e.

I am writing high-performance DTLS server which can accept thousands of connections concurrently.  

Originally, I decided, DTLSv1_listen would be called inside the listener thread, once DTLSv1_listen returns 1 i.e. successful, a new async socket will be created, it will be bound (using bind) and connected (using BIO_connect) with DTLSv1_listen returned address. 
This new socket will be passed to service thread, BIO_set_fd will set this fd and SSL_accept will be called from service thread to complete the remaining handshake and data exchange etc.

But behavior is not same as above, I have to call SSL_accept  after bind and connect inside the listen, where DTLS handshake is completed. If SSL_accept is not called then DTLSv1_listen is continuously called and always return 1 in listener thread. 

Could you please guide to resolve this issue or how to write multi-threaded dtls server where connection acceptance can be done inside the listener thread using DTLSv1_listen?

Thanks in Advance,
Anand

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: DTLS in multi-thread and concurrent connection acceptance environment

Matt Caswell-2


On 28/11/17 14:01, Anand Choubey via openssl-users wrote:
> But I do not know, whether DTLSv1_Listen/SSL_accept in the listener
> thread is capable to deal with thousands concurrent connection
> establishment. Is there known limitation around it? 

I don't know if anyone has ever created any metrics on how far it can be
scaled. I've certainly not seen it if they have. But there are no known
limitations on this approach (this is the intended way to do things).

Matt

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users