[Haskell-cafe] TLS package server interface do not seem to allow for asyncrhonious communication

[Mads Lindstrøm]

Hi Antoine,


Rereading my earlier post, I can see I did not explain myself properly.
What I do now with sockets is:

1. Bind a socket to a port

2. Call Network.accept, then take the resultant Handle, and call forkIO
_twice_ with the handle. Making one thread that listens for incoming
messages and one thread that sends outgoing messages. And then I go back
to one. That is, two threads for each handle.

I follow the scheme above, as my server do not follow a request/response
pattern, but is asynchronous and must never get blocked by a client that
do not send messages.

Why do I not think, I cannot do the same thing with the TLS package?
Because of this API description:

"recvData :: Handle -> TLSServer IO ByteStringSource

recvData get data out of Data packet, and automatically renegociate if -
a Handshake ClientHello is received"

Thus, recvData will not only read messages from the handle, it may also
do a handshake. I presume that a handshake will both send and receive
data. Thus, I would have thread that just sends data, and another thread
that both sends and receives data. I am afraid that the two threads may
"step on each others toes". With ordinary sockets, I have one thread
that only sends data, and another thread that only receives data. So
with ordinary sockets there is no chance of "stepping on each others
toes".

Also the TLSServer monad contains state. If I start two threads using
the same SSL connection, I presume that the TLSServer-state will be
different for the two threads. And I presume that two threads using the
same SSL connection, needs the same state in the TLSServer monad.

One workaround is use two SSL connections for each client, but I would
like to avoid that.


Regards and hope I make myself clearer,

Mads

On Tue, 2010-12-14 at 17:20 -0600, Antoine Latter wrote:
> Maybe I'm missing something - but shouldn't the code listening on the
> Handle already be in it's own thread?
> 
> The general recipe is:
> 
> 1. Bind a socket to port
> 2. Call Network.accept, then take the resultant Handle, call forkIO
> with the TLS actions and the resultant handle. Go back to 1.
> 
> So even though the TLS code blocks on the handle, that's in a
> different thread from the code which is waiting on the socket to
> accept additional connections.
> 
> Take care,
> Antoine
> 
> On Tue, Dec 14, 2010 at 2:21 PM, Mads Lindstrøm
> <mads.lindstroem at gmail.com> wrote:
> > Hi Haskeleers,
> >
> > I got a working SSL server using the TLS package. Great. However, I
> > really intended to use SSL for an asynchronous server. That is, the
> > server must constantly listen for a client message, which may result in
> > zero or more messages send _to_ the client. And the server will, without
> > being waken up by a client message, send messages to the client.
> >
> > And this interface
> > http://hackage.haskell.org/packages/archive/tls/0.3.1/doc/html/Network-TLS-Server.html do not seem to allow for an asynchronous server. That is, whenever I call:
> >
> > recvPacket :: Handle -> TLSServer IO (Either TLSError [Packet])
> >
> > or
> >
> > recvData :: Handle -> TLSServer IO ByteString
> >
> > The server is stuck until the client sends a message. Or am I missing
> > something?
> >
> > Contrast this to Network package socket implementation. Here I can spawn
> > two threads and simultaneously listen for client messages and send
> > messages to the client.
> >
> > It seems to me that a general SSL implementation should not preclude
> > asynchronous servers. I know, the TLS package is not more than a few
> > months old and one can already use it for SSL servers and clients, which
> > is quite impressive. So do not read this as a negative comment, more as
> > suggestions for a better interface.
> >
> >
> >
> > Regards,
> >
> > Mads Lindstrøm
> >
> >
> >
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >