On Tue, Jun 26, 2001 at 04:45:32PM +1000, Ronnie Sahlberg wrote:
> The tcp-dissector would process packet 1 and since it is not associated with
> any reassembly requests it would
> call dissect-rpc. dissect-rpc would se that this packet only contains 10
> bytes, but the rpc header says that the entire
> command is 30 bytes,
If by "RPC" you mean ONC RPC, RPC headers don't say things such as that
- instead, they say "here's a fragment that contains XXX bytes", and
possibly say "this is the last fragment".
Perhaps most of the type an RPC request or reply consists of only one
fragment, but it'd be nice to be able to handle requests or replies that
don't.
Note also that some TCP reassembly might not be byte-count based -
consider, for example, a text-based protocol such as FTP or SMTP or HTTP
or...; a line in a message might cross a TCP segment boundary.
I'd be inclined, instead, to have a "byte stream reassembly" package,
similar to the fragment-reassembly package used by IPv4, IPv6, and CLNP,
which allows a subdissector to say "add the following data to the item
currently being assembled", and leaves it up to the subdissector to
decide when the item is complete.
It could also allow the client of the package to specify a size for the
item; the routine would keep track of the amount of data in the item
and, if a size was specified, return a "the item is complete" indication
if there's no more data to be put in the item, and also return an
indication of how much of the data most recently handed to it *didn't*
go into the item, if any - this might take some of the burden off of
most of the sub-dissectors.
The only service provided by the TCP dissector would be supplying data
from the TCP data stream in order, with duplicate data removed - just as
the only service provided by a TCP stack is to supply data in order with
no duplicates. (Actually, the urgent pointer is supplied as well; we
already supply that.)
