On Mon, 16 Feb 2004 16:27:31 -0600, Edwin Calo wrote:
> On Mon, 2004-02-16 at 07:46, Joerg Mayer wrote:
> > PS: If I understand your code correctly, the the dissector currently doesn't
> > even recognize PDU borders. Would you be interested in working on that?
> Sure, I will be interested on working on PDU borders.
> Any good example I can take a look?
Unfortunately, from the PostgreSQL protocol description at
http://www.phpfreaks.com/postgresqlmanual/page/protocol-protocol.html
and subsequent pages, there probably isn't a good example, as the
PostgreSQL protocol doesn't work the way most other packets-over-TCP
protocols work, with a header with a length field.
*Some* messages have length fields, such as:
CancelRequest
PasswordPacket
SSLRequest
StartupPacket
and the others just have a one-byte opcode. As the length appears to be
32 bits, in network byte order, *and* probably isn't bigger than 2^24,
you can *probably* assume that, if the first byte is 0, the message
starts with a length field - or, alternatively, assume that if it
doesn't begin with one of the letters that's used as an opcode, it
begins with a length field.
However, as you can get a capture that starts at an arbitrary place in a
TCP stream, the best thing to do is assume that if it neither begins
with one of those letters nor begins with a zero byte, you're in the
middle of a message; finding the beginning of the next message would
probably be difficult, if not impossible, but the right way to handle
that would probably be to treat the TCP segment as undissected data and
hope that the next segment starts a new message.
Unfortunately, for the packets that begin with a one-byte opcode, the
length isn't always easy to determine - for an AsciiRow message, for
example, it can only be determined if you've seen the previous
RowDescription message.