Authentication Protocol Security - Server Responses
(Page 4 of 7 )
Once the server receives a command, it processes it and sends one or more response packets. Several types of responses are discussed in this section.
Data Field Data fields are critical components in many of the server response packets. A data field consists of a length specifier sequence followed by the actual data value. The length specifier sequence can be understood by studying the definition of net_store_ length() from sql/pack.c:
char *
net_store_length(char *pkg, ulonglong length)
{
uchar *packet=(uchar*) pkg;
if (length < (ulonglong) LL(251))
{
*packet=(uchar) length;
return (char*) packet+1;
}
/* 251 is reserved for NULL */
if (length < (ulonglong) LL(65536))
{
*packet++=252;
int2store(packet,(uint) length);
return (char*) packet+2;
}
if (length < (ulonglong) LL(16777216))
{
*packet++=253;
int3store(packet,(ulong) length);
return (char*) packet+3;
}
*packet++=254;
int8store(packet,length);
return (char*) packet+8;
}
As you can see, if the value of length does not exceed 251 (i.e., if it can fit into 1 byte without a conflict with the reserved values), the code just stores it in a byte. If it is 251 and higher but fits into 2 bytes, the code prefixes it with the value of 252 and then writes it out in the following 2 bytes. If 2 bytes is not enough, but 4 would do, the code uses 253 for the code, and then occupies the next 4 bytes with the length value. If 4 bytes is not enough, the code uses 254 for the code, and stores it in 8 bytes. It must be noted that all length values following the code are stored with the low byte first.
One may ask why the 1 byte length is limited to 251, when the first reserved value in the net_store_length() is 252. The code 251 has a special meaning. It indicates that there is no length value or data following the code, and the value of the field is the SQL NULL .
Why such a complexity? Most of the time the data field is fairly short, and, espe cially if a query returns a lot of records and/or selects a lot of columns, there could be many of them in the response. Wasting even a byte per field in this situation would add up to a large overhead. The probability of a field length being greater than 250 is relatively low, but even in that case, wasting a byte is barely noticeable since the server is already sending at least 253 bytes: at least 2 for the length, and at least 251 for the field value.
Immediately after the length sequences is the actual data value, which is converted to a string representation.
In the pre-4.1 versions, the standard server API call for storing a data field in a buffer is net_store_data() , which exists in several variants, one for each possible data argument type. The net_store_data() family is found in sql/net_pkg.cc in those older version. Versions 4.1 and higher use Protocol::store() , which in the case of the simple protocol, just wraps around net_store_data() . Both are implemented in sql/protocol.cc.
Note that in version 4.1, when returning the data for prepared statements fields and when the data value is not a string, the data is sent in the raw binary format with the low byte first without a length specifier.
Next: OK Packet >>
More Database Articles Articles
More By O'Reilly Media
|
 This article is excerpted from the book Understanding MySQL Internals, written by Sasha Pachev (O'Reilly, 2007; ISBN: 0596009577). Check it out today at your favorite bookstore. Buy this book now.
|
|
