Point 2 is simple, in the abstract. A ranged listener behaves exactly like a set of simple listeners. Doesn’t Racket’s tcp-listen already support IP ranges?

For Point 3, I think the combinator-style cascade of stream consumers design works well in Racket.

I found my stale axon HTTP code and threw it in a repo. https://github.com/dedbox/old-axon-http

The interesting bits are in the http folder and parse.rkt.

That’s axon/http and axon/parse.rkt

There’s a base http-message struct, specialized by the http-request and http-response sub-structs. The base carries an input port and collects headers as they are parsed.

It’s up to the message consumer to read the body afterwards.

I went a little nuts on parsing syntax. This might be my first attempt to syntax-parse.

This might also be when I decided to embrace exceptions over the monadic style spaghetti you see in there.

Actually, the stop and kill handlers in axon came from this use case. Originally, I wanted to kill sub-parsers without closing the port, and stop top-level parsers when I’m done with the port.

net2 probably won’t need many parsers, so a simpler design might suffice.

Point 4, I still haven’t used disposable. I’ll start adding it to axon to get a feel for it.

and congrats on the legal stuff

@dedbox re tcp-listen: yup it does, but only in the limited sense of listening to everything via the broadcast address or listening to both the ip4 and ip6 forms of an address.

re cascading stream combinators: mhm, agreed. maybe we’ll just have to try implementing a few protocols and see what exactly we need

re http stuff: neat, thanks for putting that up - ill peek at it