[ntar-workers] On Markers and Bookmarks

[Jose M. Gonzalez]

Hi, 

My 2 cents on the markers&bookmarks issue: 

- I think we should add 2 new block types that facilitate faster 
	navigation on NTAR traces, namely backward and forward blocks (REW, FF).
	Both REW and FF blocks will just be composed of an offset to the next 
	marker.

	          /---------------------------------\
	          |                                 |
	+-------+-|--+-------+-------+-----+-------+v------+-----
	| block | FF | block | block | ... | block | block | ...
	+-------+----+-------+-------+-----+-------+-------+-----

- This solution permits just fast navigation, without the use of Vern's 
	tcpslice hack, which as Christian mentioned, is not bullet-proof. 

- This solution is not a bookmarking method. Bookmarking, I agree with 
	Christian, may require something more flexible and richer than just 
	timestamps. Moreover, you may want to apply different bookmarkings to 
	the same trace. I'd store bookmarkings as different files. 

- SHB can't be used for this, as they are a complete reset of the dumping 
	process. This means you must repeat the interface blocks after every new 
	SHB. I prefer adding FF/REW blocks. Same functionality than SHBs, no 
	need for repeating interface blocks. Moreover, you can spaghetti 
	several index chains together, if you so like. 

- I won't add packets/bytes/timestamps information to the REW and FF 
	blocks. The goal of REW and FF blocks is to permit jumping several 
	blocks in one step, not counting the information on them. In the 
	forward marker case, and assuming the file is written sequentially, 
	I can't see how to decide how many packets/bytes will be before the 
	next marker when writing the FF marker. 

- If the block pointed by an FF is a REW pointing back to the FF block, 
	and the block following the REW is another FF, navigating in both directions 
	would be extremely easy. This should be made "good practice," or maybe even 
	made mandatory if using FF/REW at all. OTOH, using FF/REW should never be
	made mandatory (it may be to expensive). 

	                /---------------------------------\      /----->
	                |                                 |      |
	+-------------+-|--+-------+-------+-----+-------+v----+-|--+--
	| block | REW | FF | block | block | ... | block | REW | FF |...
	+---------|---+^---+-------+-------+-----+-------+-|---+----+--
	          |    |                                   |
	      <---/    \-----------------------------------/

- It's easy for a dumper to add FF blocks in a sequential fashion. In 
	order to add a FF block, it decides the oofset it wants to use, and 
	writes the FF block with such offset. Then, it starts writing blocks, 
	decrementing the offset with each one. Following LEGO's idea, the dumper 
	stops dumping packets when it reaches zero. It may have to pad the rest 
	(yes, we need a padding block). The next block is a REW with the same 
	offset than the previous FF. Repeat the process until the end. 

Regards. 
-Chema