On Thu, Dec 16, 2010 at 2:38 PM, Mads Lindstrøm <mads.lindstr...@gmail.com> wrote: > 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.
Ah, I see. I'm not sure how a different interface would help you here - you would still have the problem of not being able to send on the socket until after the Handshake finished. Maybe a better interface would be along the lines of: -- | Do not use the handle when you are done! openTLSConnection: Handle -> { information? Maybe not needed} -> IO TLSConnection And then some thread-safe operations on the TLSConnection: recv :: TLSConnection -> Int -> IO ByteString send :: TLSConnection -> ByteString -> IO () But I don't know much about either TLS nor the existing TLS library, so there might be some very good reasons that this won't work. Antoine > > 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.lindstr...@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@haskell.org >> > http://www.haskell.org/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe