[#CORE-2530] Denser data stream and better prefetch logic in the network protocol

Firebird Core

Denser data stream and better prefetch logic in the network protocol

Created: 26/Jun/09 10:19 AM Updated: 18/Jan/16 06:02 PM

Component/s:

Engine

Affects Version/s:

None

Fix Version/s:

3.0 Beta 1

Issue Links:

Relate

This issue relate to:

~~CORE-2897~~ Don't send full length of field over the wire when field is null

QA Status:

No test

Description

« Hide

Firebird 2.1 has already a improved network protocol, but it is still slow for internet connections (ADSL, etc). With globalization, it is a must that the protocol work better with internet connections. Private talks with Dmitry Yemanov and Vlad shows that there is still room for improvement so, here is the request.

All

Comments

Change History

Subversion Commits

Sort Order:

[ Permalink | « Hide ]

Pavel Cisar added a comment - 26/Jun/09 04:14 PM

Please, stop spamming the tracker. If you want to raise the importance of any particular entry, use the voting system, not comments.

[ Permalink | « Hide ]

Fausto Alves added a comment - 26/Jun/09 06:04 PM

This is an important implementation, since MySql, Post Gree sql, include this feature and believe that the Firebird should also comtempla it.
Yeah, I like many other users would be assisted in their needs.

[ Permalink | « Hide ]

Ricardo Cardoso added a comment - 26/Jun/09 07:19 PM

I'm working in a project with FB2.x in a network but I have plans to put on the Internet but using FB. Actually I'm using MySQL 5.0 for this because I'm worried with the protocol performance over the internet. Having this changing I can abandon MySQL and use only FB.

Regards,
Ricardo.

[ Permalink | « Hide ]

Dmitry Yemanov added a comment - 26/Jun/09 08:26 PM

I have removed all the comments of the "it's great!" style as they may hide the "on-topic" technical comments and they don't belong to the bug tracker in general, as already mentioned by Pavel. Please use the voting facility, it's enough to express your wishes.

[ Permalink | « Hide ]

Luciano Ferreira added a comment - 30/Jul/09 10:09 AM

It's very important...

[ Permalink | « Hide ]

Joao Americo fabrício added a comment - 08/Oct/10 11:28 AM - edited

I think it is very important as it will, probably, "stop" people "moving" their project from FB to Mysql when they need to add any internet issue.

I did not checked if FB already got it done, but add some kind of "compression" to packets/protocol as mysql/mssql/oracle/postgres/sybase do should be the first step.

PS. Please, use the "," (coma) at the right place to make your post easy to understand. As Im brazilian I anderstood, but ppl that does not talk in Portuguese will understand really NOTHING.

[ Permalink | « Hide ]

Lars Dybdahl added a comment - 01/Feb/12 02:37 PM

A very slow process is to fetch many blobs. Fetching 100 times 100kbyte blobs takes a very long time, because each blob is fetched in it's own request. Instead, it would be very beneficial to be able to ask the server to deliver blob content immediately, as part of the same request.

[ Permalink | « Hide ]

Dmitry Yemanov added a comment - 11/Oct/14 07:08 PM

The "improved protocol" is a too flexible term that may mean lots of things, so I've adjusted the ticket title to reflect what has been improved now. Other improvement requests (e.g. blobs sent along with records) may deserve separate tickets.

In v3, the following improvements are implemented:

1) NULL flags (4 bytes per field) are replaced with a bitmap. NULL fields are no longer transmitted, except the corresponding bits in the bitmap (see also ~~CORE-2897~~). This is available for DSQL API only, so unfortunately GBAK does not benefit from this improvement (as it uses a lower level BLR API).

2) Prefetch (batch receive) algorithm is now aware of variable-length messages (VARCHARs and NULLs may reduce the transmitted message size), so more rows can be transmitted within a single batch.