yall still around? & haskell machines / scalaz-stream

[Francesco Lazzarino]

have you guys seen scalaz-streams? Its supposedly based off Haskell machines/iteratee.

https://github.com/scalaz/scalaz-stream/blob/master/src/test/scala/scalaz/stream/examples/StartHere.scala

Is the basic idea along these lines?:

reads some bytes (non-blocking)

when i get enough bytes i can read some http headers

when i get enough headers i can start parsing the body

when i get enough of the body i can start writing some stuff somewhere else (non-blocking)

in theory we write bytes to some fd before we are done reading from the original source? kinda like how select based http servers are free to handle a ton of requests, never block and stream data?

[Brian Lewis]

On 2013.08.20, at 20:05, Francesco Lazzarino wrote:
> have you guys seen scalaz-streams? Its supposedly based off Haskell
> machines/iteratee.

I haven't looked at Scala for a while.

I think the new hotness in Haskell for this stuff is pipes and conduit:
http://hackage.haskell.org/package/pipes
http://hackage.haskell.org/package/conduit

They basically want to be able to parse stuff in fixed space, close
handles/sockets predictably, and parse what's available and leave the
rest for later when there's more data. Other than that, I don't know too
much about them.

I'm really interested in stuff like that for making robust network
servers and clients. For example, lots of servers can be slow-played by
clients that send one legal byte at the slowest allowed rate, like H ...
T ... T ... P ... etc. And about a billion FTP clients use "readline"
functions that will read any number of characters looking for a newline.

[Francesco Lazzarino]

with the slow-play interaction they still handle it correctly but at (virtually) no expense to the rest of the requests being handled?

with ftp clients, is the risk that a newline will never come? how does that effect the server?

i'll take a look at pipes and conduit. are machines passè? thanks!

--
You received this message because you are subscribed to the Google Groups "GainesvilleHaskell" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gainesvillehask...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
franco

[Brian Lewis]

On 2013.08.21, at 11:06, Francesco Lazzarino wrote:
> with the slow-play interaction they still handle it correctly but at
> (virtually) no expense to the rest of the requests being handled?

Yeah. And I think they're in a good position to know they're being
slow-played. But I haven't had time to check on this myself with pipes
and/or conduit.

Basically, it's usually a mistake for servers to think everything is OK
as long as they hear something from the client within some amount of
time. It's more like they need to recieve a complete request from the
client within a certain amount of time, or something like that.

> with ftp clients, is the risk that a newline will never come?

Right. If you write a network service scanner that collects banners
and/or tries to interact with the services to find out about them or
check basic things, you have to deal with all kinds of weird stuff.
People may put chargen on port 21.

Servers and clients both really need to protect themselves.

> are machines pass�?

I've heard they're cool, but sort of experimental. pipes and conduit are
the industrial-strength packages right now.