Thread: Old backend/frontend protocol versions

Hello everybody.

I'm Daniel Varela, the developer of DBBalancer, a load balancing connection 
pool for PostgreSQL (http://www.sourceforge.net/projects/dbbalancer), and 
I've recently been faced to a problem with protocol versions. DBBalancer 
speaks itself Postgres protocol to open and close connections, while 
forwarding all other messages. Currently implements protocol version 2.0, as 
defined in the documentation.

The problem appeared when using DBBalancer with PostgreSQL and PHP installed 
from Debian packages, as a tcpdump capture identified a StartUp packet like 
this:

00 00 01 28 04 d2 16 2f ...

According to the protocol specification the first four bytes are the length 
of the packet (ok), but the next four should be the protocol version....

What I would like to know, since the lack of documentation (at least I 
couldn't find any) of previous versions of the protocol is:

a) Is this really a previous version of the protocol?
b) Is it worth to implement it in DBBalancer?
c) If it is, where could I find documentation about it? I know that the 
source code "somewhat" documents it, but it would be very very time saving to 
have access to some docs.

Best regards and thanks in advance.



-- 

----------------------------------
Regards from Spain.  Daniel Varela
----------------------------------

If you think education is expensive, try ignorance.          -Derek Bok (Former Harvard President)

Daniel Varela Santoalla <dvs@arrakis.es> writes:
> The problem appeared when using DBBalancer with PostgreSQL and PHP installed 
> from Debian packages, as a tcpdump capture identified a StartUp packet like 
> this:
> 00 00 01 28 04 d2 16 2f ...
> According to the protocol specification the first four bytes are the length 
> of the packet (ok), but the next four should be the protocol version....

This is an SSL negotiation request --- look for NEGOTIATE_SSL_CODE
in the sources.

> What I would like to know, since the lack of documentation (at least I 
> couldn't find any) of previous versions of the protocol is:

The people who did the SSL feature did a spectacularly poor job of
documenting it.  AFAICT, the rest of that packet is a wasted bunch of
zeroes, and the next thing that happens is that the postmaster sends
back a one-byte OK-to-use-SSL-or-not response; if OK, the next step
is to engage in an SSL connection dialog, then send the real StartUp
packet under protection of SSL.  But no, there's not a word of
documentation about it except some comments in the source code.

Unless your balancer can cope with a stream of data that it cannot make
any sense of, my guess is that you'll have a hard time doing anything
useful with SSL-encrypted connections.  You might be best off to reject
them out of hand (send back a 1-byte response 'N', then wait for the
non-encrypted StartUpPacket).  Or perhaps run separate SSL sessions on
your incoming and outgoing datastreams.
        regards, tom lane