[erlang-questions] Asynchrous Ssl Listen/Accept

[Essien Ita Essien]

Essien Ita Essien wrote:
> I've continued *staring* at code and also trying to achieve asynchronous 
> recv as well, and the following are what I've found. I want to sort of 
> just run my finding through list and pick up the collective wisdom.
> 
> (all code from ssl-3.9)
> 
> First asynchronous recv.
> 
> The main clause for ssl_prim:recv is defined as:
> 
> ssl_prim:recv(St, Length, Timeout) when record(St, st), St#st.status =:= 
> open ->
> 	inet_tcp:recv(St#st.proxysock, Length, Timeout)
> 
> Can I then safely assume that after all the ssl handshake is done, I can 
> call the St#st.proxysock directly to get decrypted data?
> 
> Also, I notice that only inet_ssl_dist consumes ssl_prim. Anything I 
> should be wary of there? (And ssl_prim still uses the broker for some 
> things, transport_accept and ssl_accept for example).
> 
> On the async accept side of things, I traced and finally found out that
> the PORT actually sends us async notifications of the form:
> 
> {Port, {data, Binary}}
> 
> And ssl_server pulls out the opcode (i'm guessing SSL Protocol OpCode) 
> from the Binary and does a case based action depending on the opcode.
> 
> I'm guessing that right now then, the current implementation doesn't 
> have any way for me to intercept the various operations then. If maybe 
> instead of the case, ssl_server had notified another layer, then maybe I 
> could conceivable intercept it *cleanly*.
> 
> Any clarifications, any additional thoughts?
> 
> For my application, I'm beginning to think I should create my own async 
> layer atop the exposed ssl layer, using a spawned process to do blocking 
> accept and recv and notifying my main process asynchronously.
> 
> Why I initially wanted to hook into the under-belly, was to prevent 
> myself from adding yet *another* abstraction layer onto what's already 
> existing, which could potentially affect performance, not to mention add
> needless code if the functionality I want already exists.
> 
> cheers,
> Essien
> 
> 
> Essien Ita Essien wrote:
>> Hi all,
>>
>> I'm investigating the possibility of having asynchronous ssl accept'ing 
>> in an application. (Prefarably using new_ssl, though if old is what I
>> need, then I have no prolems using it)
>>
>> Basically, something akin to the prim_inet:async_accept/1 trick for tcp 
>> listeners.
>>
>> I'm a few months old in erlang, so trying to peruse the ssl source code 
>> gave me more than a few bouts of migrane, and I'm not helped by not 
>> groking the ssl protocol flow really.
>>
>> Is there any where I should look to find this, maybe a pointer in the 
>> right direction. What's throwing me off, is I can't seem to find the 
>> division b/w the new_ssl and the old ssl implementation. I have traced 
>> as far as ssl_connection:accept, but from there, i get very lost, very fast.
>>
>> Any help, much appreciated.
>>
>> cheers,
>> Essien

I've made lots or progress after experimenting lots.
I can now do full asynchronous accept using new_ssl implementation,
and upgrading the connection on both sides. First, I follow a recipe 
similar to:

http://www.trapexit.org/Building_a_Non-blocking_TCP_server_using_OTP_principles

And when i recieve:

{inet_async, ListenSock, Ref, {ok, ClientSock},

I proceed to upgrade ClientSock like:

ssl:ssl_accept(ClientSock, [{verify, 0}, {cacertfile, 
"/path/to/cacert.pem"}, {certfile, "/path/to/cert.pem"}, {keyfile, 
"/path/to/key.pem"}).

This works allright for async ssl accept.

My intial test with prim_inet:async_recv on the original ClientSock, 
after upgrading the connection gives me data which i assume to be the 
ssl protocol envelope, i'm still playing around hoping for success on 
async recv as well. When all is done, I'll post some code incase someone 
else wants to do this.

cheers,
Essien
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>>
> 
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>