This has been on my TODO list for awhile. Hopefully I can produce this sometime this year. For now the only way to learn the protocol is via the client and server source code.
As a starting point, ODBTP is a binary protocol that involves the exchange of packets that contain a four byte header followed by variable byte length data. The 4 byte header is interpreted as follows:
My reason for looking into this side of things, is that for a few years I've been looking for "ODBC via HTTP". ODBTP seems to be very close, and it may just solve my problem with getting Php to talk to a 64 bit SQL Server.
But what I originally was looking for, was a way to launch your own backend, e.g. as a number of (Php) scripts, on any server, including *nix, enabling any ODBC capable client to communicate with local databases on the server via plain http.
If you've figured out a protocol for the job, then an ODBC client utilizing this may not be so far fetched after all. :-)
I'll go look at the source code. Just wanted to hear whether the documentation were "hidden" somewhere I couldn't figure out :-)
Best regards,
Lars
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The reason why I created a special TCP/IP protocol for this task instead of HTTP is because HTTP is a text protocol and is stateless. Text protocols have considerably lower efficiency and performance than binary protocols. Also, a stateless protocol like HTTP makes it unsuitable for performing databaae transaction commits and rollbacks. The primary advantage of a HTTP protocol, i.e., SOAP, is that it does not require the creation of a client side API like the one used to create the PHP odbtp extension. Currently, ODBTP can only be easily leveraged by C or PHP developers (a third-party Python interface is also available).
The decision to use a binary protocol instead of a HTTP protocol, is because speed was more important than broad access across all programming languages.
NOTTE: Before I created ODBTP, I looked at a HTTP / SML solution called ODBCSock. Although it could be used by any programming language, it was very slow, could not be used for database transactions, and did not support UNICODE queries.
-- bob
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The protocol seems never to have been officially documented. The official page - http://odbtp.sourceforge.net/protocol-index.html - is blank.
Is it documented anywhere, except of course in the C++ source code itself ?
Best regards,
Lars
Hi Lars
This has been on my TODO list for awhile. Hopefully I can produce this sometime this year. For now the only way to learn the protocol is via the client and server source code.
As a starting point, ODBTP is a binary protocol that involves the exchange of packets that contain a four byte header followed by variable byte length data. The 4 byte header is interpreted as follows:
Byte 1: ODBTP Request Code (client) or ODBTP Response Code (server)
Byte 2: Flag indicating whether or not this is the last packet (0=No, 1=Yes).
Bytes 3 - 4: Byte length of data following the header
How the data following the header is interpreted is determine by the Request Code or Response Code. The codes are listed in the odbtp.h file.
-- bob
Thanks Bob,
My reason for looking into this side of things, is that for a few years I've been looking for "ODBC via HTTP". ODBTP seems to be very close, and it may just solve my problem with getting Php to talk to a 64 bit SQL Server.
But what I originally was looking for, was a way to launch your own backend, e.g. as a number of (Php) scripts, on any server, including *nix, enabling any ODBC capable client to communicate with local databases on the server via plain http.
If you've figured out a protocol for the job, then an ODBC client utilizing this may not be so far fetched after all. :-)
I'll go look at the source code. Just wanted to hear whether the documentation were "hidden" somewhere I couldn't figure out :-)
Best regards,
Lars
The reason why I created a special TCP/IP protocol for this task instead of HTTP is because HTTP is a text protocol and is stateless. Text protocols have considerably lower efficiency and performance than binary protocols. Also, a stateless protocol like HTTP makes it unsuitable for performing databaae transaction commits and rollbacks. The primary advantage of a HTTP protocol, i.e., SOAP, is that it does not require the creation of a client side API like the one used to create the PHP odbtp extension. Currently, ODBTP can only be easily leveraged by C or PHP developers (a third-party Python interface is also available).
The decision to use a binary protocol instead of a HTTP protocol, is because speed was more important than broad access across all programming languages.
NOTTE: Before I created ODBTP, I looked at a HTTP / SML solution called ODBCSock. Although it could be used by any programming language, it was very slow, could not be used for database transactions, and did not support UNICODE queries.
-- bob