Dmitry Yemanov wrote:

>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.
>
>

Remote performance is a factor of round trips, cpu per trip, and bytes
sent, in that order. Unless cpu per trip is really gross, the cost is
bounded by round trips.

To a large degree, the number of trips is determined by the SQL standard
and the need to provide timely error notification. Exceptions are when
you able to predict with reasonable certainty what the next call is
likely to be. Batching records is the obvious example.

On one hand, it is also obvious that returning describe information
necessary for an application to build an SQLDA should be returned
automatically to eliminate a round trip. Even better, however, is to
eliminate the need to SQLDAs to be built at all.

A huge step forward, however, would be to eliminate the blob calls,
sending up to the first 64K (or whatever) with the record, incurring
another trip only if it's really big. Or just byte the bullet and send
all blobs always. After all, if the client didn't want the blob, it
wouldn't have asked for it.

Please keep in mind that in the original design I wanted to avoid
allocating memory during message processing. Machines are bigger and
faster now, and this doesn't make a rat's ass worth of difference now.
Also keep in mind that the DSQL part of the protocol was designed by our
"politically correct" colleages at Borland, so there may be no reason
for what they did other than bad table manners.

>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).
>
>

I remember that this was discussed at length with regards to the new
data encoding. Are you suggesting something different?

>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.
>
>

Having already published the results comparing run length encoding to
the new record encoding, I'm surprised that we still have an advocate of
run length encoding. If we going to compress, it makes sense to use
something much better like zlib.

Another consideration is the desirability to multiplex event messages
over the primary pipe. This suggests an architecture with a pipe
listener thread reading and queuing messages rather than a strict
request / response line protocol.

For the record, the remote interface / server I implemented for the Rdbs
(and presumably still in use at Oracle) had all messages received and
queued at AST level. This worked then because DECnet was message, not
stream, oriented and VMS had decent AST support. Unix signals were and
are pathetic, but threads change the picture entirely.

What I would like to see is a careful study of round trips in situ with
the present protocol (data, gentlemen, not just ponderings!) with an eye
to a modest extension of the existing protocol. Then a major
re-architecture for the new API well after FB 3.