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
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-S... 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@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe