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