On Thu, 22 Nov 2001, Ronnie Sahlberg wrote:
> > I've completed preliminary work on the outer TDS protocol (netlib). Next
> > up is the TDS protocol proper.
>
> Cool.
> I have one thought though,
> Is netlib dedicated to only carry the TDS protocol or can it carry other
> protocols as well?
netlib only carries TDS. Although, I should be specific when I say this,
there are around half a dozen different packet types in TDS which share
nothing in common with each other.
> Can a netlib PDU span multiple TCP packets?
Generally speaking there is one netlib header per tcp segment. There are
a few esoteric cases where multiple netlib packets can be sent in a single
tcp segment, but that is easy to deal with. I've never seen the reverse
happen though (one netlib packet to multiple tcp segments) but I suppose
it is allowed to be chopped up like that by the tcp stack. I haven't
quite decided how to deal with those yet.
> If it can not, i.e. a netlib PDU must fit within a single TCP segment, then
> the length field in the header would not make sense?
>
> If TDS is dedicated only to encapsulate TDS and also if netlib PDUs can span
> multiple TCP segments
> then you could consider the following enhancements
> 1, remove the part of the heuristic check that checks the length of the
> netlib PDU being equal to the length of the captured
> payload.
> 2, instead, since (according to the assumption made above) netlib only
> carries TDS PDUs, check beyong the netlib header, inside
> the TDS PDU to strenghten the heuristics for detecting netlib (so it will
> not be too weak) (if possible)
The problem is that TDS itself is hard to do heuristics on because it is a
handful of different formats (logins, queries, cancels, and responses
mostly). Logins can be detected by a variety of fixed fields, currently
I'm looking at protocol version major numbers.
Response packets in particular are difficult to check because they may
start anywhere in the middle of a PDU and the token fields could be
anything. In the last fragment of the stream the TDS payload could
potentially be a single byte.
> 3, add TCP-desegmentation to netlib so it can also handle netlib PDUs which
> spans multiple TCP segments.
Advice on how to go about this? This is really a corner case and probably
rarely if ever happens (packets are always sent as a whole to the tcp
stack, and are typically less than mtu size, 512 bytes by default), but
I'd like to cover it nonetheless.
> 4, add a mechanism so netlib can handle multiple netlib PDUs inside a single
> TCP segment.
This one is fairly easy, netlib contains its own size field and therefore
the tvb subset can be called repeatedly for each payload.
> As an alternative, drop 1 and 2 and only do 3 and 4 if you already have seen
> login packets in the conversation which identifies the
> conversation as being netlib and nothing else.
This was the best I could come up with. There just doesn't seem to be a
good way of identifying the stream otherwise. Although I am adding some
logic to detect query packets. TDS 5.0 in particular has strong
semantics, and I think I can make do in TDS 4.2/7.0/8.0 by checking a size
field (altough size field inside the TDS protocol is now endian dependant
unlike netlib).
I think this will be ok, since without capturing the first packet coming
back from the server immediately after the query packet, dissecting the
response is hopeless.
> See packet-diameter.c for an example on how to use tcp-desegmentation. it is
> fairly easy.
Disregard my previous query, then. ;-)
Thanks for the help. And happy thanksgiving for those in the states,
Brian
