[ntar-workers] On Markers and Bookmarks

[Gianluca Varenni]

----- Original Message ----- 
From: "Loris Degioanni" <loris.degioanni at gmail.com>
To: <ntar-workers at winpcap.org>
Sent: Thursday, June 30, 2005 10:45 AM
Subject: Re: [ntar-workers] On Markers and Bookmarks


>
>
> 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.

I like the idea, too. And, as loris said, I don't know what is the actual 
benefit (in terms of pure speedup in the seek operations) that we can obtain 
with this approach vs. one using multiple sections (and duplicated IDBs). I 
hope to find some time in the next weeks to make some tests, and see what 
happens.

GV


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