[CUWiN-Dev] simulation for testing & protocol verification

[Chase Phillips]

Thanks for sending this in, Dave.  I've been too busy with my paid life to
investigate HSLS proactively so it's a big help to have this info spelled
out.

Dave's spot on in why I value simulating our software.  It started as an
interest in just understanding HSLS to watch how information propagates in
a controlled environment.  Then after getting to a certain level in my own
toy simulator I began to understand how big the project could be.  I dug
back into searching for useful simulation frameworks with a renewed
interest in not having to write one of our own. :)

I finally found JiST (Java in Simulation Time) and a driver that runs on
top of JiST named SWANS (Scalable Wireless ...).  The appeal of this
framework is that it models time universally to all of its internal
components and allows those components to explicitly bump time in a
step-wise fashion (rather than time just nastily incrementing itself
implicitly as I've heard it is prone to do).

  http://jist.ece.cornell.edu/

I don't discount the gravity of change that would need to happen to HSLS
for it to be refactored into a reusable set of library routines.  As Dave
suggests, it's better right now to treat the HSLS router code as
unverified (we'd be testing nightlies throughout on-going development,
after all) and let the OS shield us from regressions/mem bugs.

Chase

On Wed, 9 Feb 2005, David Young wrote:

> Chase has been talking to me about plugging hslsd into a simulator
> for testing, debugging, and protocol verification.  Here is a summary
> of changes to be made to hslsd before we can run it in a simulator.
> I am assuming throughout that each simulated router will consist of a
> new hslsd instance, the simulator will control the passing of simulated
> time in each hslsd instance through a UNIX-domain socket, and all of the
> HSLS packets will be exchanged between hslsd instances and the simulator
> (who may drop/forward/damage the packets) over UNIX-domain sockets.
>
>         * gettimeofday(2) calls need to be replaced by calls to
>           a hsls_time_gettime() method of a hsls_time object.  We need
>           both gettimeofday(2) and simulator-time implementations.
>           The simulator-time implementation has to read (from a AF_LOCAL
>           socket?) the current time from the simulator.
>
>         * Wherever hslsd expresses a timeout in an event(3) library call,
>           we need to wrap that call in something that tells the simulator
>           to schedule a timeout event, and we need to invoke the right
>           callback when that simulator event occurs.  (Presumably the
>           simulator will indicate the event on an AF_LOCAL socket.)
>
>         * hslsd needs to support a third address family, AF_LOCAL.  hslsd
>           needs to put a fake network header in front of the HSLS packets
>           it sends over AF_LOCAL sockets.
>
>         * hslsd needs to bind(2) UNIX paths given by -a options.
>           It needs to understand UNIX paths in -p options.
>
>         * hslsd may need to interpret prefix lengths differently for
>           AF_LOCAL sockaddrs than for AF_INET{,6} sockaddrs.
>
>         * The socket library needs improvements to deal with AF_LOCAL
>           sockets.
>
> The simulator has to change, also.  It has to connect with all of the
> hslsd instances' sockets, it has to send them its notion of the current
> time over sockets every simulator step, and so on.
>
> There are other ways to approach this problem.  Chase suggested making
> a library libhsls out of hslsd, linking that library with a simulator,
> and letting the simulator instantiate hsls_router objects and hand them
> references to "received" packets, etc.  My main concern with doing it
> that way is that there is no isolation: if we have several instances of
> a potentially buggy hslsd under test, and they run in the same address
> space, then tripping over a bug in one instance might kill off one or
> more other instances.  A secondary concern is that more invasive changes
> may be necessary to turn hslsd into a library for simulation than to
> run several hslsd instances.
>
> Dave
>
>