On Fri, 28 Jun 2002, Patrick McHardy wrote: > Hi everyone, > i know this is not the right place to discuss this, but i assume some > people here might have some good ideas which could help me. > Also, i don't really know where else to turn .. I'll see if I can help. [snip] > A TCP usually takes care of this (wraparound after min. 24.8 days), but > this will not be true anymore. if we choose our timestamp clock to > increase once every 1 ms the sign bit will wrap after 5.5 minutes. I'm > not sure what to do about this (this is why i'm writing), does anyone > here have good ideas? I would also be happy about a completly different > approach, somehing totaly passive would be nice .. :) The completely different approach would be to recognize all TCP streams running through the machine and keep clocks for them: store the most recent RTTM SYN time for a particular stream as well as the current time of the machine when that RTTM time was seen. This will give you a good enough approximation of the clock-skew between what you would put in the RTTM field yourself and what is in there already, allowing you to use the RTTM fields if they already exist. Note that this takes 64 bits, i.e. 8 bytes of storage per TCP stream, and tracking of all active TCP streams running through your machine. However, the latter is probably necessary *anyway* if you are going to do rate control, as you're bound to want to store the windowsizes and stuff related to each TCP stream separately. Doei, Arthur. -- /\ / | arthurvl@sci.kun.nl | Work like you don't need the money /__\ / | A friend is someone with whom | Love like you have never been hurt / \/__ | you can dare to be yourself | Dance like there's nobody watching _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
