Hi Ronnie,
see my comments in-line.
Best regards
Michael
On Jul 8, 2005, at 10:37 AM, ronnie sahlberg wrote:
If you implement it in SCTP and base it on the TCP one, dont just copy
the TCP one straight over. Use it for ideas but now with more
accurate understanding of the problemspace it can be implemented
better than the TCP one with some refactoring.
OK.
The TCP one has evolved over the last few years into features not
originally planned for so there are things that are sub-optimal in
there.
For example, the TCP one does do quite a few redundant
look-up-hashtable that slows it down a bit.
I see.
I use very little SCTP myself and am not too read up about it, I am
refactoring the code in tcp-graphs now to tappify it and thus get rid
of the restriction of the very limited set of transports supproted (at
the expence of doing a dissect of the packets ==> major slowdown in
tcp-graph initialization expected).
Maybe you want to look into massaging the tcp-graph thing to also
support SCTP at a later stage?
What tcp-graph stuff are you talking about? The throuput, Byte versus
time,
and so on graphs? We have such stuff already built in.
Any specific things that are very different in SCTP compared to TCP i
should be aware of when refactoring this code to not make it more
diffucult than neccessary if you want to SCTPify it later?
The major difference is that it supports multihoming (so the
conversation
stuff has to be extended) and it numbers and acks DATA chunks and not
bytes. There can be multiple DATA chunks per packet.
On 7/8/05, Jeff Morriss <jeff.morriss@xxxxxxxxxxx> wrote:
Michael Tuexen wrote:
Yes, you are right. I mixed the stuff up. So the right place
would be
the dissector.
Jeff, so do you think that it would be useful?
Yes, in fact that's exactly what I am looking for... I have a
capture
file with so many retransmissions and duplicate SACKs that it
makes my
head spin--especially when I try to sort out the mess. (Of
course, it
also made Ethereal crash in the TSN graph stuff--thus bug #280. ;-))
Regarding your (Michael's) multi-homing question: I agree that this
could be an issue, but analyzing at least what's in the capture
file we
have would be a start. And by using Linux (capture on "all"
devices) or
'mergecap' we can get all the packets in one file for analysis if
need-be. This assumes, of course, that the analysis stuff could/
would
track the associations by Vtag and not just by the IP addresses in
the
current packet.
Regards,
-Jeff
Michael Tuexen wrote:
But I think (maybe I'm wrong) is that the sequence number
analysis
was developed earlier than the tap stuff.
And the other thing is that the sequence number stuff is not link
layer independent like it would be it
it done via taps.
To which sequence number analysis are you referring?
I was referring to the analysis the results of which show up in the
protocol tree, which is the one that detects retransmissions,
duplicate ACKs, etc.; that code is link-layer independent, as it's
done in the dissector.
It sounds as if you're talking about the TCP graphs, which aren't
link-layer independent (and which should be redone as a tap to make
it link-layer independent).
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
