"Roman Rokytskyy" <rrokytskyy@...> wrote:

>
> That's basically all improvements that we can make on the protocol
> level with the current API.

I see most of you talk about redundant roundtrips but this is not the only
problem of the protocol. There are also issues with too many bytes sent
across the wire.

1) All data descriptors are sent fully expanded, including NULLs and CHAR
strings. Could be solved via variable-length encoding of the data (protocol
internals change).

2) The server replies with a number of bytes allocated by the client
regardless of how many actual bytes are being returned. This is okay for
fetches when we already know size of the record packet, but this wastes a
lot of traffic for describe/info calls. Could be solved via passing the
buffer length as a reference to adjust it at the server side (API change).

Both these issues are effectively eliminated with a simple RLE compression,
but we don't support it yet. Perhaps such a workaround would be much easier
to do than redesign/reimplement the API. Just add an optional packet-level
compression which is enabled if and only if both sides support the new
protocol version. The question is how to turn this feature off for those who
already use compression provided by Zebedee or alike tools.


Dmitry