Server Administration

  Home arrow Server Administration arrow Authentication in Client/Server Commun...

Authentication in Client/Server Communication
By: O'Reilly Media
  • Search For More Articles!
  • Disclaimer
  • Author Terms
  • Rating: 5 stars5 stars5 stars5 stars5 stars / 1

    Table of Contents:
  • Authentication in Client/Server Communication
  • Command Packet
  • Command Packet: Server Responses
  • OK Packet



    Authentication in Client/Server Communication

    (Page 1 of 4 )

    In this second part of a three-part series on client/server communication, you'll learn about authenticating handshakes, handling command packets, and more aspects of the MySQL client/server protocol. It is excerpted from chapter four of the book Understanding MySQL Internals, written by Sasha Pachev (O'Reilly, 2007; ISBN: 0596009577). Copyright 2007 O'Reilly Media, Inc. All rights reserved. Used with permission from the publisher. Available from booksellers or direct from O'Reilly Media.

    Authenticating Handshake

    Table 4-5. Protocol capability bits (continued)



    Bit macro symbol

    Hex value




    This flag will be set for all modern clients. Some old clients expect to receive only 1 byte of flags in the field definition record, while the newer ones expect 2 bytes. If this flag is cleared, the client is old and wants only 1 byte for field flags. This flag will also be set by the modern server to indicate that it is capable of sending the field definition in the new format with 2 bytes for field flags. Old servers (pre-3.23) will not report having this capability.



    This flag is also set for all modern clients and servers. It indicates that the initial default database can be specified during authentication.



    If set, the client is asking the server to consider the syntax db_name.table_name.col_namean error. This syntax is normally accepted.



    When set, indicates that the client or the server is capable of using the compressed protocol.



    Apparently was created to indicate that the client is an ODBC client. At this point, it does not appear to be used.



    When set, indicates that the client is capable of uploading local files with LOAD DATA LOCALINFILE.



    When set, communicates to the server that the parser should ignore the space characters between identifiers and subsequent . or ( characters. This flag enables syntax such as: db_name .table_name or length (str) which would normally be illegal.



    When set, indicates that the client or the server is capable of using the new protocol that was introduced in version 4.1.



    When set, the client is communicating to the server that it is accepting commands directly from a human. For the server, this means that a different inactivity timeout value should be applied. The server has two settings: wait_timout and interactive_timeout. The former is for regular clients, while the latter is for the interactive ones. This distinction was created to deal with applications using buggy persistent connection pools that would lose track of established connections without closing them first, keep creating new ones, and eventually overflow the server max_connectionslimit. The workaround was to set wait_timeoutto a low value that would disconnect the lost connections sooner. This, unfortunately, had a side effect of disconnecting interactive clients too soon, which was solved by giving them a separate timeout.



    Table 4-5. Protocol capability bits (continued)



    Bit macro symbol

    Hex value




    When set, indicates the capability of the client or the server to use SSL.



    Used internally in the client code in versions 3.23 and 4.0. SIGPIPEis a Unix signal sent to a process when the socket or the pipe it is writing to has already been closed by the peer. However, a thread in a threaded application on some platforms may get a SIGPIPEsignal spuriously under some circumstances. Versions 3.23 and 4.0 permit the client pro-grammer to choose whether SIGPIPEshould be ignored. Version 4.1 just blocks it during the client initialization and does not worry about the issue from that point on.



    When set in the packet coming from the server, indicates that the server supports transactions and is capable of report-ing transaction status. When present in the client packet, indicates that the client is aware of servers that support transactions.



    Not used.



    When set, indicates that the client or the server can authenti-cate using the new SHA1 method introduced in 4.1.



    When set, indicates that the client can send more than one statement in one query, for example:

    res = mysql_query(con,"SELECT a FROM t1 WHERE id =1; SELECT b FROM t1 WHERE id=3");




    When set, indicates that the client can receive results from multiple queries in the same statement.



    Internal flag used inside the client routines. Never sent to the server.



    More Server Administration Articles
    More By O'Reilly Media

    blog comments powered by Disqus


    - SSH Case Studies: Gateway Hosts
    - SSH Case Studies: More on Pine and SSH
    - SSH Case Studies: Pine and IMAP
    - SSH Case Studies: More on the Passive Mode
    - SSH Case Studies: Network Address Translation
    - SSH Case Studies: The Passive Mode
    - SSH Case Studies: The FTP Protocol
    - SSH Case Studies: Batch Jobs, FTP and SSH
    - SSH Case Studies: Agents and Authentication
    - SSH Case Studies
    - Server Responses to Client Communication
    - Authentication in Client/Server Communication
    - Client/Server Communication
    - Understanding Awk in the UNIX Shell
    - Stream Editor in the UNIX Shell

    Developer Shed Affiliates


    © 2003-2019 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap