[erlang-questions] Asynchrous Ssl Listen/Accept

Essien Ita Essien me@REDACTED
Sat Dec 13 08:56:50 CET 2008


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
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
> 




More information about the erlang-questions mailing list