Re: [MirageOS-devel] Concerning testing network protocols

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

> On 27 Mar 2015, at 17:10, Richard Mortier <richard.mortier@xxxxxxxxxxxx> 
> wrote:
> 
> All;
> 
> I've been wondering about something recently and thought I'd throw the
> question open as I'm a bit stumped :)
> 
> At present we have many implementations of various network protocol
> wire format de/serializing code, which is rather unsatisfactory.  It
> seems nice to reduce these to one implementation per protocol.
> 
> We also have a pcap trace parsing library, `pcap-format`. Currently,
> some libraries use `pcap-format` as part of their unit testing, eg.,
> `ocaml-dns`.
> 
> I've been playing around hacking in support to `pcap-format` to use
> `ocaml-dns` to parse captured DNS packets, and have hit an obvious
> snag: using `ocaml-dns` to parse DNS packets in `pcap-format` perhaps
> invalidates using `pcap-format` to unit test `ocaml-dns`, and
> certainly leads to issues when trying to build and install each of
> them.
> 
> So-- how should this be handled? A few (almost wholly unsatisfactory)
> options came to mind:
> 
> 0. Leave things alone and simply be careful about when unit tests in
> protocol libraries are turned on.

I dont think this an option, since building with tests should not
introduce cycles into the build graph.

> 1. Split all wire format de/serialization code out of each protocol
> into a distinct library. Link against this library in both
> `pcap-format` and `ocaml-<protocol>`. Unit test the protocol
> implementation separately (perhaps via property-based testing which
> might not require a separate implementation, perhaps relying on
> completely distinct implementations like `libpcap`).

This one sounds best to me.  Although, it sounds like there's a
certain amount of feature creep going into pcap-format.

Why not just parse the raw pcap format in pcap-format, and have a new
pcap-format-analysis library that depends on both pcap-format and ocaml-dns?

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