Rami AlHasan wrote:
But, please, if I have a skinny message that is segmented between two
TCP packets, how can I tell "from the first packet" that I have a
completion segment in another packet?
If you have the first segment containing the Skinny message, and the
Skinny message begins at the beginning of the segment, you have the
header of the Skinny message and know where it is in the segment; a
Skinny message begins with a 4-byte big-endian length field, which is
the length of the data in the message. Add 8, which is the length of
the header, to that value, and you have the total length of the packet.
If that's longer than the length of the TCP segment, the message is
continued in subsequent TCP segments.
Is there helping info in TCP header that informs me of the existence of
the pending bytes in the second packet?
Not in the TCP header. TCP knows nothing about packet boundaries for
protocols running atop TCP.
Or, from the skinny header info, I get the message length, and If the
remaining bytes in the current packet are less than the message length,
then I will conclude that the difference bytes are sent segmented in the
next packet.
Correct.
However, to read a Skinny record, your application should probably just
do something such as
bytes_to_read = 4;
length = 0;
while (bytes_to_read > 0) {
byte = read_a_byte_from_the_tcp_stream();
length = (length << 8) + byte;
bytes_to_read--;
}
length += 4; /* we already read the length, there are 4 more bytes left */
bytes_to_read = length;
while (bytes_to_read > 0) {
read a byte from the TCP stream;
add it to the buffer for the record;
}
You can probably optimize it so that you try to read as many bytes as
possible from the segment into a buffer, and then extract bytes from the
buffer.
That will handle both multiple records in a TCP segment and multiple TCP
segments for a record.
(Note that Ethereal *already* does Skinny reassembly, if the preference
for that *and* the general preference for TCP reassembly are turned on.)
Also, I think that in both cases I have to use the TCP sequence number?
No, because your TCP implementation will deliver bytes from the TCP
connection in order. (This is presumably part of an implementation of
the Skinny protocol, *NOT* part of changes to the Ethereal Skinny
dissector, as that dissector *already* does desegmentation.)