[Haskell-cafe] Long-running request/response protocol server using enumerator/iterator/iterIO/pipes/conduits/...

[Michael Snoyman]

On Tue, Jun 26, 2012 at 10:22 PM, Nicolas Trangez <nicolas at incubaid.com> wrote:
> Hello Cafe,
>
> Some time ago I tried to implement a network service using iteratee (or
> enumerator, can't remember), but gave up in the end. More recently I
> wanted to create something similar (a similar protocol), but failed
> again.
>
> So I'm looking for some example code or something similar (Google only
> helped slightly).
>
> First of all, I don't care which API/library to use, I guess for my
> purpose all of enumerator, iteratee, iterIO, pipes, conduits,... are OK,
> so all feedback is welcome.
>
> Here's the catch. Most examples out there implement some server which
> accepts a single client request, interprets it, creates a response,
> returns this, and closes the connection (or something alike, think
> HTTP).
>
> The protocol I'd like to implement is different: it's long-running using
> repeated requests & responses on a single client connection. Basically,
> a client connects and sends some data to the server (where the length of
> this data is encoded in the header). Now the server reads & parses this
> (binary) data, sets up some initial state for this client connection
> (e.g. opening a file handle), and returns a reply. Now the client can
> send another request, server parses/interprets it using the connection
> state, sends a reply, and so on.
>
> Might sound easy (and actually it's pretty easy in most other languages
> I know, including an OCaml implementation), yet I fail to figure out how
> to get this done using some enumerator-style library.
>
> Thanks for any help, I'll most likely write up something if I get things
> working for future reference.
>
> Nicolas
>
>
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe

I've run into those kinds of problems in the past as well. In general,
interleaving of data streams can be difficult with enumerator. That's
the reason I added connect-and-resume to conduit. I use the technique
in warp[1], which in fact *does* support multiple request/response
pairs due to connection keep-alive. But the code base isn't the
easiest introduction to the technique. If there's interest, I'll try
to put together a blog post on using connect-and-resume to solve this
kind of problem.

Michael

[1] https://github.com/yesodweb/wai/blob/beta/warp/Network/Wai/Handler/Warp.hs#L296