List:Internals« Previous MessageNext Message »
From:Michael Widenius Date:October 15 2001 9:40pm
Subject:New server/client protocol
View as plain text  
Hi!

I just wrote a short specification for an extension of the
client/server protocol and wanted to hear if anyone would have any
comments regarding this.

------------
We need to extend the client/server/protocol with the following features:

- Get warnings from the server (for any command).
  Two ways to do this:
   - Maintain a linked list in the server with warnings for the last command
     that can be retrieved with SHOW WARNINGS.
     - The client should for each command send to the number of warnings
       (like we now send affected rows).
   - Send warnings as marked 'warning rows' during execution of the command.
     - We should send up to SQL_WARNING_LIMIT rows to the client.
- Add 'progress' packages to the protocol and let the client register a
  callback function that will be called for each progress package.
  This allows the client to implement a 'progress bar'.
  The package should include two numbers:  Current record position and
  estimated end record position.
  This doesn't have high priority, but should be thought of.
- For each column send also the database and real table name (now only the
  alias is sent).
  The new MYSQL_FIELD structure in 4.0 already have these columns.
- For threaded clients, add an option to specify execution time for the client.
  (Should be implemented with thr_alarm and a signal handler thread).
  This doesn't have high priority, but should be thought of.
- mysql_prepare(MYSQL *, const char query, uint query_length);
  mysql_bind_execute(MYSQL *, uint param_number, MYSQL_BIND *bind)
  mysql_execute(MYSQL *);
  - In the BIND structure, there should be 'ulong *length' pointer from where
    one can retrieve the length for FIELD_VAR_STRINGS columns.
  - The interface should automaticly convert the bind data to the column
    type that the server wants.
  - mysql_bind_for_execute() will fill in the MYSQL_BIND structure with
    data about the parameter (like type, max_length...)
- mysql_option(MYSQL *, MYSQL_OPT_BIND_RESULTS);
  mysql_bind_result(MYSQL *, uint column_number, MYSQL_BIND *bind)
  This should be used by clients that wants to bind the result to variables.
  One has to bind all columns in the result.
  mysql_fetch_row() will convert data and update the bound variables.
- Remove compatiblity with old 3.21 clients (one should still be able to
  configure with -DUSE_OLD_FUNCTIONS to keep the server compatible with these).
- New 'virtual' field type for BIND:  FIELD_TYPE_STRING_POINTER.
  If this is used, we will update a string pointer to point to where the data
  is.  Note that if this means that if the data is a packed number,
  the mysql_bind..() function has to allocate space to where we should
  store the value.

Requirements:
- Old clients >= 3.22.0 should work as before.
- All binary data should be sent with low byte first.
- We should support at least the following 'fast native' types for BIND:
  - signed and unsigned integer (1-8 bytes)  
  - float
  - double
  - strings
  - datetime (Should be sent as packed number)
  All other types should be sent as strings
- Keep the interface 'clean'; Better to require the user to specify all
  BIND options than have entries that are optional.
  (This will make it much easier to write a really fast interface).
- One should implement BIND (prepare and fetch) so that it's easy to
  integrate this with the MyODBC driver.
- We should allow bind arguments 'anywhere';  We should return
  FIELD_TYPE_VAR_STRING for parameters for which we can deduce a type.


Benefits (of BIND):
- The server doesn't have to convert numbers to strings before sending them
  to the client.
- The clients doesn't have to convert numbers to strings or escape strings
  when using PREPARE.


Disadvantages:
- Bigger client library.
- A lot of convert functions in the client (double->string ...)
- More things to document and test.
- Need of more examples.
-------------

Regards,
Monty
Thread
New server/client protocolMichael Widenius16 Oct
  • Re: New server/client protocolJochen Wiedmann16 Oct
    • Re: New server/client protocolMichael Widenius17 Oct
  • Re: New server/client protocolSinisa Milivojevic16 Oct
  • Re: New server/client protocolJeremy Zawodny20 Oct
    • Re: New server/client protocolSinisa Milivojevic20 Oct
    • Re: New server/client protocolMichael Widenius24 Oct