[Scamper-dev] scamper

[Matthew Luckie]

> The most pressing topic is about leaving scamper as it currently stands,
> a single run application, or make it more skitter like, continiously
> probing it's destination list until halted externally.

i don't think that this is a biggie.  i'll write some code to make it loop
on an address list.

my understanding of unix files is that until i close a current file
handle, i'll still access the old copy of a file even if a new one has
been written over the top of the old one.  so, I will not close the file
handle at the end of reading a list, unless there is a new address list,
which is indicated with a SIGHUP at any stage before I get to the end of
the list to indicate that there is a new list for me when i finish this
list.

> Also do we wish to make the fileformat compatable with the current skitter
> so we can reuse the skcollect (etc) code?

from what i can tell at a glance from the arts++ page, writing a to_arts.c
file shouldn't be too hard, for scamper purposes.  i notice that in
http://www.caida.org/tools/utilities/arts/libArts/html/ArtsIpPath.html
that the code appears to only talk IPv4 addresses, so a limited amount of
work might have to be done to your existing tools and scripts.

is there a page somewhere that gives me the IP Path layout binary file
format for arts?

as for the rest of your description: the only other thing I have missing
is code to handle the case where you don't hear anything for 5 hops.  I'll
write some code to handle that as well.

as far as i can tell, I don't need to deal with the process of actually
retrieving an address list.

this is what my current file format looks like:

 * the first 4 bytes declares how many addresses the scamper has seen (i.e.
 * how many elements to allocate for an array big enough to hold all the
 * addresses when reading the output of a scamper)
 *
 * the file format consists of a series of trace records.
 *
 * a trace record begins with a 1-byte field that has the address family
 * encoded in the first bit (0 for IPv4 addresses, 1 for IPv6 addresses),
 * with the other seven bits storing the length of the path (i.e. how many
 * hop records to read).  the next 4 (for IPv4) or 16 (for IPv6) bytes
 * consist of the address that we are probing on this trace if we have
 * not seen it before, else the index of the address so we don't repeat
 * ourselves.  then we have trace->hop_count number of hop records;
 *
 * a hop record consists of:
 *
 *  - a one byte `type' field that signifies
 *     - if this hop had no response                        (0x00)
 *     - if this hop uses a previously used IPv[46] address (0x01)
 *     - if this hop declares a new IPv[46] address         (0x02)
 *
 *  - if we probed an address for this hop:
 *
 *    - if the hop type uses a previously used IP address, then the next
 *      four bytes consist of an index into the address seen.
 *
 *    - if the hop type uses declares a new IP address, then the next series
 *      of bytes (4 bytes for IPv4 trace, 16 bytes for IPv6 trace) consist of
 *      the address.
 *
 *  - the delay seen between sending the UDP probe packet and the reception
 *    of the ICMP destination unreachable packet with a 4 byte entry
 *
 * the last byte of a trace record contains the result of the trace

there is a lot of wasted space in this file format.  if you care, then i
have code to write a file as a bitstream, but this seems over kill if all
we want is something simple and sane.