On 11 August 2004 14:19, Glynn Clements wrote:
Right. If listenOn and accept are in Network, sClose should be in there too. That would at least provide an API which is usable for the simplest programs.
Sounds reasonable. I'll add it.
OTOH, the core problem with Network.recvFrom is essentially that it appears to be a misguided attempt to provide a symmetric counterpart to Network.sendTo. While the low-level sendTo/recvFrom functions may be roughly symmetric, at a higher level, the client and server ends of a connection aren't at all symmetric.
Yes, I'm sure that's the reason for it. Proposals for a replacement are welcome... Cheers, Simon
Simon Marlow wrote:
OTOH, the core problem with Network.recvFrom is essentially that it appears to be a misguided attempt to provide a symmetric counterpart to Network.sendTo. While the low-level sendTo/recvFrom functions may be roughly symmetric, at a higher level, the client and server ends of a connection aren't at all symmetric.
Yes, I'm sure that's the reason for it. Proposals for a replacement are welcome...
What would be the intended purpose of a replacement?
If you want a simpler interface for writing servers, it would probably
look something like:
doServer :: PortID -> (Handle -> IO ()) -> IO ()
doServer port handler = do
s <- listenOn port
let doIt = do
~(s', _) <- Socket.accept s
h <- socketToHandle s' ReadWriteMode
forkIO $ handler h >> hClose h
sequence_ $ repeat doIt
Ultimately, you either need to create a separate thread/process per
connection, or manually service multiple connections (select/poll). A
server which processed connections sequentially wouldn't be of much
practical use (and a one-shot server probably wouldn't even be of use
for "toy" programs).
--
Glynn Clements
On 2004-08-13 at 21:53BST Glynn Clements wrote:
Simon Marlow wrote:
Yes, I'm sure that's the reason for it. Proposals for a replacement are welcome...
What would be the intended purpose of a replacement?
If you want a simpler interface for writing servers, it would probably look something like:
doServer :: PortID -> (Handle -> IO ()) -> IO () doServer port handler = do s <- listenOn port let doIt = do ~(s', _) <- Socket.accept s h <- socketToHandle s' ReadWriteMode forkIO $ handler h >> hClose h
Shouldn't there be sCloses in here?
sequence_ $ repeat doIt
Otherwise that looks like a much handier thing, though there /might/ be call for something without the forkIO.
Ultimately, you either need to create a separate thread/process per connection, or manually service multiple connections (select/poll). A server which processed connections sequentially wouldn't be of much practical use
Well, for the to application I had in mind when I started this thread, sequential processing of connexions is exactly what's wanted. Whoever makes the first connexion gets control and keeps it until they drop the connexion, then the next client takes over.
(and a one-shot server probably wouldn't even be of use for "toy" programs).
Indeed not! -- Jón Fairbairn Jon.Fairbairn@cl.cam.ac.uk
participants (3)
-
Glynn Clements -
Jon Fairbairn -
Simon Marlow