linkend="protocol-message-formats"/>.)  There are
   several different sub-protocols depending on the state of the
   connection: start-up, query, function call,
   <command>COPY</command>, and termination.  There are also special
   provisions for asynchronous operations (including notification
   responses and command cancellation), which can occur at any time
   after the start-up phase.
  </para>

  <sect2 id="protocol-flow-start-up">
   <title>Start-up</title>

   <para>
    To begin a session, a frontend opens a connection to the server and sends
    a startup message.  This message includes the names of the user and of the
    database the user wants to connect to; it also identifies the particular
    protocol version to be used.  (Optionally, the startup message can include
    additional settings for run-time parameters.)
    The server then uses this information and
    the contents of its configuration files (such as
    <filename>pg_hba.conf</filename>) to determine
    whether the connection is provisionally acceptable, and what additional
    authentication is required (if any).
   </para>

   <para>
    The server then sends an appropriate authentication request message,
    to which the frontend must reply with an appropriate authentication
    response message (such as a password).
    For all authentication methods except GSSAPI, SSPI and SASL, there is at
    most one request and one response. In some methods, no response
    at all is needed from the frontend, and so no authentication request
    occurs. For GSSAPI, SSPI and SASL, multiple exchanges of packets may be
    needed to complete the authentication.
   </para>

   <para>
    The authentication cycle ends with the server either rejecting the
    connection attempt (ErrorResponse), or sending AuthenticationOk.
   </para>

   <para>
    The possible messages from the server in this phase are:

    <variablelist>
     <varlistentry>
      <term>ErrorResponse</term>
      <listitem>
       <para>
        The connection attempt has been rejected.
        The server then immediately closes the connection.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>AuthenticationOk</term>
      <listitem>
       <para>
        The authentication exchange is successfully completed.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>AuthenticationKerberosV5</term>
      <listitem>
       <para>
        The frontend must now take part in a Kerberos V5
        authentication dialog (not described here, part of the
        Kerberos specification) with the server.  If this is
        successful, the server responds with an AuthenticationOk,
        otherwise it responds with an ErrorResponse. This is no
        longer supported.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>AuthenticationCleartextPassword</term>
      <listitem>
       <para>
        The frontend must now send a PasswordMessage containing the
        password in clear-text form.  If
        this is the correct password, the server responds with an
        AuthenticationOk, otherwise it responds with an ErrorResponse.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>AuthenticationMD5Password</term>
      <listitem>
       <para>
        The frontend must now send a PasswordMessage containing the
        password (with user name) encrypted via MD5, then encrypted
        again using the 4-byte random salt specified in the
        AuthenticationMD5Password message.  If this is the correct
        password, the server responds with an AuthenticationOk,
        otherwise it responds with an ErrorResponse.  The actual
        PasswordMessage can be computed in SQL as <literal>concat('md5',
        md5(concat(md5(concat(password, username)), random-salt)))</literal>.
        (Keep in mind the <function>md5()</function> function returns its
        result as a hex