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... j. On Thu, Nov 12, 2015 at 9:45 PM, Hannes Mehnert <[email protected]> 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 > [email protected] > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel > >
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
