[Tcpick-project] New mechanism to capture data

[Francesco S. <dus...@in...>]

This is the explanation of the new mechanism of fragments.c (code
comments).
Actually I am developing a way to track the tcp session in the healtiest
way. These new features will be available in tcpick 0.1.23 (max 2
weeks, including debuggin) and will be a big step in the development.
When the code is too complicated and doesn't work it is the time to
rewrite it, isn't it? ;)
Why are these improvement so important? You could download passively a
very big compressed archive via ftp without data corruption!

/*
 * Explanation of this code (fragments.c)
 * ======================================
 *
 * The stream of data of the tcp connection will be saved on 
 * the file, but we know that tcp connection aren't datagram-oriented, 
 * but stream-oriented! This means we *must* rebuild the disordered 
 * flow. The problem is: we cannot store entire tcp connections in
 * memory! This is simply crazy! What if somebody is downloading cd
 * iso images, or dvd films! They will surely corrupted.
 * Solution: write the rebuilded part of tcp flow in the file when
 * there are no missing pieces; so we will be able to store in memory
 * the "early coming" packets and when the "latest" (sorry for the bad
 * english) could complete the stream, flush this part of the flow to
 * the file.
 *
 * Phase 1:
 *     Picking up the packets containing data from the interface.
 * 
 * Packets containing data fragments are stored into the chained 
 * "fragments_noack" dinamically-allocated structs. "_noack" 
 * means that these data are not yet acknowledged with the "ack"
 * packet of response. 
 * The packet are chained with the "->next_struct" trick, and are
 * ordered sequentially following the offset of the data calculated
 * from the seq field. 
 * 
 * Phase 2:
 *     Acks are arriving!
 * 
 * These are the acks of the stored but not acknowledged packets.
 * Simply, they acknowledge the packet. This way the packet can go in
 * the "fragments_ack" chained struct. This chain is very similar to
 * the "fragments_noack", but contains only 100% tcp-acknowledged
 * data. (We can trust the tcp stack of the host, hopefully).
 * 
 * Phase 3:
 *     Flush! (a.k.a. writing the rebuilded stream to file)
 * 
 * My preferred part: data that are ordered by the systems above
 * descripted will be written to the file in that way:
 * If the offset of the data just written to the file is equal to the
 * offset of the first packet, write it to file and deallocate it. 
 * Now control the now first ring of the chain and check it again,
 * until a NULL (end of the chain) is reached, or a offset is not like
 * the one of data written.
 *
 */

What do you think about it?
Cheers,
- Francesco

-- 
http://francesco.stablum.info
Key fingerprint = 521D DAD3 EB81 B62B FE35  E644 8CAD C1FC 66C8 246F
Non mandatemi allegati in formati proprietari (msword, excel ecc.)
uso GNU/Linux, preferite formati quali pdf, html e testo semplice (txt),
grazie http://wecanstopspam.org