[Scamper-dev] scamper notes draft 1

Bradley Huffaker bhuffake at caida.org
Wed May 19 11:30:20 PDT 2004


Let me know of any changes before I send it to scamper-dev.


--------------------------------------------------------------------
    Review from last meeting ouput Records
--------------------------------------------------------------------

Start Cycle Record -	This marks the beginning of the cycle and lists
			the set of options which will be used for the comming 
			cycle.  These options can include: collect hop RTT,
			number of tries for a non responsive hope,or to 
			use source routing.

Ip Path Record -	This holds a the collection of information which
			is collected and stored when probing to a single
			destination and a fixed set of Source Routed IPs.

MTU Path Record -	This will hold the collection of information which
			was collected for a given destination and a fixed
			set of Source Routed IPs.

--------------------------------------------------------------------
    How to handle Lists and duplicate IPs
--------------------------------------------------------------------

We have decided to split the role of list managment and list probing
into to two processes.  Scamper will be the probing process and there
will also be a ListManager process to handle the list creation and
interleaving of different lists.

On a local port, or some other communication channel, Scamper will request
the next batch of IPs from the List Manager.  The List manager may send it
an IP Object, Begin List Object, or End List Object.  
    Ip Object  - contains destinations to prob 
	 contains:IP, ListId, and CycleId.  
    Begin List Object  - marks the beginning of the current cycle and 
	sets up the options that will be used to prob the IP address
	contains:ListId, CycleId, list of Options for use this cycle, and 
	    human readable text field.  
    End List Object - marks the end of a list and causes scamper to
	free up resources assigned to it once it has finished the
	current cycle.
	contains: ListId

To help me explain the behavor we would like scampe to have I will assume,
for now, that it has the following lists:
    Active Window - the list of IP Object which are currently being probed
    Input Queue - the list of Objects which were passed by the List Manager
	but have yet to be processed or moved to the active list
    Pending Queue - each ListId gets a pending queue which holds
	Object from a different cycle then the current cycle.
    Blocked Queue - holds a list of IP Objects which are blocked
	because their IP address is currently in the queue.  These
	Lists are stored with the active IP Object which is blocking 
	them.

Scampe should garrentee that the following two statements are true:
    * IP addresses from different Cycles, but the same List are not 
      probed, in the active list, simultaneously.
    * Only one occurance of the same IP addresses will be found in
      the active list.

Scamper will maintain an Active Window of IP Objects.  When scamper
finishes probbing an IP Object in the Active Window it saves it's data to
disk, removes it from the Active Window, and the next IP Object in the
Input Queue, proved the conditions listed below are not meet, will be moved
into the Active Window.

Scamper will maintain state of the current active CycleId and ListId pairs
and will only accept IP Object from the current active ListId and CycleId.
IP Objects found at the front of the Input Queue which do not match the
active CycleId for a given ListId will be discarded.  A ListId only has a
single active CycleId.  When a Begin List Object is found at the front of
the Input Queue it will replace the current CycleId for the ListId it
contains.

If a Begin List Object is the next object in the Input Queue and there
currently exists IP Objects of the same ListId, but different CycleId, in
the Active Window then the Begin List Object is sent to a List dependant
Pending Queue.  Each ListId is given it's own Pending Queue.  Pending
ListId Queues are read preferentially to the Input Queue.  If there are
multiple Pending ListId Queues they are worked through round robin until
they are empty.

Scamper will not allow multiple instances of the same IP address to be in
it's active window at the same time.  If next IP Object in the Input Queue
has an IP address which is the same as an IP address already in the Active
Window it will put that IP Object at the end of Blocked Queue attached to
the active IP Object whose IP address it contains.  When that active IP
Object is to be removed from the Active Window if it's Blocked Queue is not
empty the first IP Object in it's queue is added to the Active window and
the remaining IP Objects in the Blcoekd Queue are added to this newly
activeated IP Object.

--------------------------------------------------------------------
    How to handle save files
--------------------------------------------------------------------

Scamper will now continuesly write data to disk.  It will therefor not
periodically release the lock on it's output file.  Instead when skdatad
wishs to access scamper's output it will send scamper an interupt and start
trying to get it's own lock on the file.  When scamper recieves the
interupt it will finish what ever record it was writting, get a new lock on
a new file, release the lock on the old file, and start writting data to
the new file.  When scamper releases the lock on the old file skdatad will
be able to process the file at it's leisure.


More information about the Scamper-dev mailing list