> The stream could be huge. Think FTP and 2G files. :)
In that *particular* case, you'd probably not bother to reassemble the
FTP data stream, just the control-command stream; we just display the
FTP data stream frame by frame; given that FTP data and control go over
two separate connections, that's not too tricky.
Using *HTTP* to retrieve a 2G file might be trickier, especially over a
persistent connection; however, even in that case, you'd reassemble the
HTTP "payload", i.e. the object being fetched, only if you want to
provide the features some have wished for, such as actually displaying
the page/image/whatever that the user fetched. And in that particular
case, you'd probably display that "out of line", i.e. it wouldn't be
part of the Ethereal protocol tree, so dumping the object being fetched
to a file and displaying that file would probably be the right way to
handle it.
A trickier issue might be, for example, an ONC RPC-over-TCP stream with
a 2G-1 fragment in it - if the ONC RPC-over-TCP dissector were to handle
multiple-frame requests and replies (and getting a packet analyzer that
could do that was what got me looking at packet analyzers in the first
place; pulling an NFS READDIR/READDIRPLUS reply apart by hand, because
snoop doesn't dissect anything past the first frame, is not something
I'd consider "fun"), it'd somehow have to handle a fragment marker that
says the fragment is 2GB in size, e.g. simply saying that a fragment
above a certain size will just not be reassembled.
("Fragment" here refers not to IP fragments, but to fragments in the ONC
RPC-over-TCP record marking standard - see RFC 1831:
10. RECORD MARKING STANDARD
When RPC messages are passed on top of a byte stream transport
protocol (like TCP), it is necessary to delimit one message from
another in order to detect and possibly recover from protocol errors.
This is called record marking (RM). One RPC message fits into one RM
record.
A record is composed of one or more record fragments. A record
fragment is a four-byte header followed by 0 to (2**31) - 1 bytes of
fragment data. The bytes encode an unsigned binary number; as with
XDR integers, the byte order is from highest to lowest. The number
encodes two values -- a boolean which indicates whether the fragment
is the last fragment of the record (bit value 1 implies the fragment
is the last fragment) and a 31-bit unsigned binary value which is the
length in bytes of the fragment's data. The boolean value is the
highest-order bit of the header; the length is the 31 low-order bits.
(Note that this record specification is NOT in XDR standard form!)
.)
This would probably not be an issue for NetBIOS-over-TCP, as the packet
length field in a NetBIOS Session Service header is 17 bits long (16-bit
length field plus one flag bit that says "add 65536 to the length
field"), so you get no more than 131072 bytes of session service
payload.