Xen project Mailing List

I think protocols have 3 APIs - there's "lower level" i/o, there's "upper level" i/o, and there's environmental (timers, resource exhausation or relief, lie out of buffer or here's some more) - the APIs can be refined a bit (init, config, and fire, read/write)

believe it or not, the OSI model is quite nice in that it describes the abstraction that a protocol provides (the higher level API offers a service, the lower level one is a use of a service, the thing in between, the state and state machine, implement something that turns the lower one into the, hopefully, simpler upper one.

the canonical example in the internet word is the reliable, flow controlled transport protocol....running over the unreliable, uncontrolled internet protocol....

so the sock stream service is effectively the pipe emulation, to make everything above tcp allegedly as simple as writing programmes that talk to infinite files (unix style)

and the datagram service below is unexpected, unreliable, and unordered messages/packets

and the machinery in the middle, your state machine, plus the api to resource management (most crucially timers), makes one out of the other...

the simplest mapping onto an implementation is to build the system as 3 cooperating threads, sharing 1 state structure (atomically:) to structure how they coordinate..but there are lots of other ways one could build that (including just a single big wait()/select()/polling:)

the other bit of the API to the lower level is what you mostly put in yr bog article - which is packet parsing (and construction) - my personal take on this is that this ought to be an easy part of the problem, but I am biased, coz I think only ad people would use ASN.1 and BER for any real world protocol, and the design of TCP and IP (without options) was cool because for a C compiler and a PDP-11 (16 bit) or vax (32 bit) it was obvious what the headers looked like (there's 20 bytes and fields are all processable in registers, and only a mad c-compiler writer would not map a c struct defined correctly into the right thing in memory (and therefore also on the wire, given a non-mad NIC), with the only glotch being the introduction of htons/htonl coz of DEC vax (and later intel) being barking mad about byte significance across words (aka unsigned ints)

but that's my 2 pence...

On Thu, Nov 12, 2015 at 9:45 PM, Hannes Mehnert <hannes@xxxxxxxxxxx> wrote:

Hey,

I just revived a draft on how to write protocols in a purely functional
way.Â The goal is that the protocol logic is independent of any side
effects, but has an explicit API what action the effectful client should
do (which a test harness could also check for, instead of putting the
bytes onto the wire).

I think the design space of software implementations is very thinly
populated, and we should try out more approaches.Â The draft is based on
experience developing TLS with David (which was my first OCaml project),
and OTR, but also experience from implementing TCP/IP in Dylan (a LISP
dialect) back in 2005 (retrospectively I can find shortcomings of that
approach much easier).

I'm eager to discuss it in further detail on this list (I'm pretty sure
it is incomplete and partially wrong).

Â https://gist.github.com/hannesm/17f478233508b42297d9

Thanks to David and Mort for feedback on earlier drafts.Â Feedback welcome,

hannes

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel

Re: [MirageOS-devel] How to implement protocols?