On Thu, 31 May 2007, Ruoming Pang wrote:
. Binpac does
not support SunRPC over TCP now. There are four extra bytes
prepended in RPC packets. Either TCP layer decoder should take care of
these extra bytes, or the RPC decoder has to do something with it. In
addition, &exportsourcedata is used in RPC/UDP decoder based on datagram
mode. It is not supported by flowunit mode. This means, we cannot simply
change the decoder from datagram mode to flowunit mode for RPC/TCP.
The way I imagine doing this is to consider RPC on TCP a trivial
lower-level protocol than RPC on UDP. For each RPC-on-TCP message, the
analyzer calls the datagram mode RPC analyzer's NewData() routine.
What do you think?
I think the problem is not that simple.
First let's look at the case of RPC/UDP, it is possible that a RPC message
is transmitted in multiple IP packets due to IP fragmentation. Either the
lower layer should reassemble the entire RPC message from IP fragments, or
just it sends the fragment pieces to the RPC decoder in order. In the second
scenario, the RPC decoder has to use flowunit mode.
In the case of RPC/TCP, the first four bytes specifies the length of a RPC
record (not necessarily be a complete RPC message from my understanding of
the RPC RFC). It is called Record Marker. Because of the stream nature of
TCP, the RPC record may be transmitted in multiple TCP packets. Although
from some traces, I see that a TCP packet always contains the four bytes
and the complete RPC message. I do not think we can make a safe assumption
that this is always true. In addition, if a RPC record is not a complete
RPC message, this introduces another problem to the RPC decoder. A complete
RPC message may be transmitted in two records, and each record is prepended
with a Record Marker. The position to split the two records can be arbitrary!
I do not see a solution in the current binpac language to handle this kind
The future is not set. There is no fate but what we make
for ourselves. - Terminator II, Judgment Day