Ethereal-dev: Re: [Ethereal-dev] [PATCH] fix for multiple dcerpc connections over single socke
On Tue, Nov 20, 2001 at 11:04:24PM -0500, Todd Sabin wrote:
> I'm not familiar with COTP, but calling them packets gets confusing
> for me. Perhaps saying NBT and SMB Named Pipes (and others) provide
> reliable byte streams with message boundaries would be more clear?
Not to me - I think of a "byte stream" as intrinsically lacking message
boundaries; if it had message boundaries, it wouldn't be a byte stream
to me.
> I think that's true for some transports, but not others. E.g., the
> case of ncacn_nb_tcp (dcerpc/nbt/tcp) seems to always put one dcerpc
> PDU in one NBSS message, but ncacn_np (dcerpc over smb named pipes)
> doesn't necessarily do that. One PDU may require several SMB Writes
> and/or Reads.
Then you're going to need your own desegmentation code for that - the
TCP desegmentation code can't help you there, as it's doing
desegmentation for NBSS, and the named pipe stuff is running atop SMB
which is running atop NBSS, so there's several layers of stuff between
DCERPC and TCP.
> > 1) the DCE RPC dissector needs to do segment reassembly anyway,
> > and can probably do the reassembly itself for TCP
>
> I think this is the wrong way to go. What is the purpose of the TCP
> desegmenting code, if not for this?
The purpose of the TCP desegmenting code is to allow a protocol running
directly atop TCP to indicate to TCP that it - the protocol running atop
it - is assembing a PDU, and that it needs N more bytes of data before
it has the full PDU.
It is *not* for desegmenting stuff at layers more than one layer above
TCP, as the intermediate layers get in the way.
Perhaps what's needed is to provide "generic" byte-stream desegmentation
code, which the TCP desegmentation code and the DCERPC code would use.
Once the DCERPC code is using it, there's no point in it asking TCP to
do desegmentation for it, as they'd be using the same code in either
case.
