Subject | Re: [Firebird-Architect] Batch/Block operations |
---|---|
Author | Alexandre Benson Smith |
Post date | 2005-02-21T21:19:19Z |
Jim Starkey wrote:
No, I have no sugestion, but I am sure that the problem with the remote
protocol resides more on the round trips than on the data transfered
itself, since anyone could feel that even if you have large bandwidth
and a big latence in the conection it will appears slow. I have just
posted it to tell Stanimir (if he doesn't already knows) that for
compression we could rely on alternatives, that could solve the
compression problem easily.
Since it has been raised a couple of times here, some sugestions had
poped up, and I can't remember of any of those that addressed all the
problems, I could think it's a real big task.
Because I think it's not an easy task I put on my original message the
following:
"I think this is the big problem :-("
James K. Lowden pointed some time ago that want to experiment the TDS
protocol (used by Sybase) since there is (IIRC) an open solution based
on this.
And you argued about that it does not fit the way FB works (I think
because of multiplexing the TCP conection and the way blobs are
retrieved). I remember that the messages exchanged had a good technical
description of the limitations.
As I pointed sometimes, I am very far away from DB Engines Design, I am
just a user, but I think I could put my nose sometimes here to try to
help :-) (At least I try !)
There is some features that makes my eyes bright, one of those are a
fast remote protocol (maybe it's just utopia, but I have hope).
I have some clients with "on-the-road" salesman, or remote offices that
uses MS Terminal Services today, because it's the only way I could make
a remote (internet) conection be as usable as a local conection.
see you !
--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br
>Alexandre Benson Smith wrote:Hi Jim !
>
>
>
>>In case you don't know it, there is a compressed/encrypted tunnel called
>>Zebedee, take a look on it.
>>
>>I think that besides the compression, the whole FB protocol should be
>>revised to minimize the round ups. I think this is the big problem :-(
>>
>>
>>
>>
>>
>>
>The protocol reflects the API. Do you have any suggestions for reducing
>the number of round trips?
>
>
>
>
No, I have no sugestion, but I am sure that the problem with the remote
protocol resides more on the round trips than on the data transfered
itself, since anyone could feel that even if you have large bandwidth
and a big latence in the conection it will appears slow. I have just
posted it to tell Stanimir (if he doesn't already knows) that for
compression we could rely on alternatives, that could solve the
compression problem easily.
Since it has been raised a couple of times here, some sugestions had
poped up, and I can't remember of any of those that addressed all the
problems, I could think it's a real big task.
Because I think it's not an easy task I put on my original message the
following:
"I think this is the big problem :-("
James K. Lowden pointed some time ago that want to experiment the TDS
protocol (used by Sybase) since there is (IIRC) an open solution based
on this.
And you argued about that it does not fit the way FB works (I think
because of multiplexing the TCP conection and the way blobs are
retrieved). I remember that the messages exchanged had a good technical
description of the limitations.
As I pointed sometimes, I am very far away from DB Engines Design, I am
just a user, but I think I could put my nose sometimes here to try to
help :-) (At least I try !)
There is some features that makes my eyes bright, one of those are a
fast remote protocol (maybe it's just utopia, but I have hope).
I have some clients with "on-the-road" salesman, or remote offices that
uses MS Terminal Services today, because it's the only way I could make
a remote (internet) conection be as usable as a local conection.
see you !
--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda.
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br