[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[MirageOS-devel] Concerning testing network protocols


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.,

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

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.

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`).

2. Make `pcap-format` the only place all wire format parsing is done,
then much as 1.

3. Simply stop protocol unit tests depending on `pcap-format`, forcing
them to express tests differently (perhaps as property-based tests
that don't need a separate implementation of `parse`/`marshall`).


Richard Mortier

MirageOS-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.