[ntar-workers] On Markers and Bookmarks

[Loris Degioanni]

Jose M. Gonzalez wrote:
> 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. 

I like the FF/REW blocks idea, and it should be quite simple to 
implement. However, do you really think that repeating interface blocks 
will be a big overhead or performance hit? It's really not cler to me.

Loris

> 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
> 
> _______________________________________________
> ntar-workers mailing list
> ntar-workers at winpcap.org
> https://www.winpcap.org/mailman/listinfo/ntar-workers
>