Protocol version 11 changes

View: New views
1 Messages — Rating Filter:   Alert me  

Parent Message unknown Protocol version 11 changes

by Vlad Khorsun-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


    Jiri Cincura asked me to describe protocol changes made in FB 2.1 to
re-implement it in .Net provider. I think it will be useful at least for Jaybird
too, so i decided to post this description here.

a) Protocol version starting from v11 encoded in such a way to distinguish
Firebird from Interbase :

// Since protocol 11 we must be separated from Borland Interbase.
// Therefore always set highmost bit in protocol version to 1.
// For unsigned protocol version this does not break version's compare.

const USHORT FB_PROTOCOL_FLAG = 0x8000;

...
const USHORT PROTOCOL_VERSION11 = (FB_PROTOCOL_FLAG | 11);


b) Starting from v11 new protocol type (ptype_lazy_send) was introduced :

/* Protocol Types */
// p_acpt_type
const USHORT ptype_page = 1; /* Page server protocol */
const USHORT ptype_rpc = 2; /* Simple remote procedure call */
const USHORT ptype_batch_send = 3; /* Batch sends, no asynchrony */
const USHORT ptype_out_of_band = 4; /* Batch sends w/ out of band notification */
const USHORT ptype_lazy_send = 5; /* Deferred packets delivery */

    If both client and server agreed on this protocol type, some types of packets
delivers in deferred mode, i.e. they sends not immediately but in combination with
another (logical) packets. Correspondingly answers on this packets also delivered
together. This reduces number of roundtrips and increased network performance.

    Below is list of packet types which delivered in deferred mode :

    op_allocate_statement, op_free_statement,
    op_close_blob, op_cancel_blob,
    op_release

    "Deferred mode" meaning : packet contents copied into buffer and not flushed into network
at the end of packet preparation. When any other packet type is about to be sent into network,
this buffer(s) sent first. The same about responses.

    Also logic of op_prepare and op_execute (op_execute2) is affected. In ptype_lazy_send
mode, server may set STMT_DEFER_EXECUTE flag (4) in p_resp::p_resp_object field in
response on op_prepare packet. This flag is set only if prepared statement have output parameters
(cursor). Client remembers if this flag was set for statement and may send following op_execute
(op_execute2) packet in deferred mode also. In this case statement started execution not when
op_execute (op_execute2) packet was sent but when next operation with this statement is performed
(op_fetch, op_info, etc). Correspondingly possible error will be returned later, not in response on
op_execute (op_execute2) packet. Hopefully it is hard to receive error before first fetch (only in
initialization code, say evaluation of initial values of declared variables of stored procedure).
Also most API wrappers (components sets, libraries, etc) often combined prepare and fetch\info
calls in the same high-level method, so from the user POV nothing is changed.



c) new packet type was introduced to support trusted authentication on Windows - op_trusted_auth (90)

    If DPB\SPB in op_create\op_attach\op_service_attach packets have no user name specified,
client may add isc_dpb_trusted_auth\isc_spb_trusted_auth  clumplet with some info obtained from OS.
Server reads this info and may ask additional info from client. In this case server will send op_trusted_auth
packet in response on initial op_create\op_attach\op_service_attach packet. Client must answer with
op_trusted_auth packet contained new portion of info obtained from OS. This process may be repeated
again, until success or failure of attachment.

    Details about what info client must ask from OS, how server is verified it, etc is out of scope of this
letter. I'm sure Alex will describe details when he came back from vacation if someone asked him ;)


d) There is few optimizations in statement preparation code and in informations requests code not
dependent on protocol. I already described it here i believe. If you can't find it, feel free to ask again ;)


Regards,
Vlad

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
LightInTheBox - Buy quality products at wholesale price