Gnutella Protocol Development

Our blue logo

Gnutella Protocol Development

Home :: Developer :: Press :: Research :: Servents

4.3 Bye Message Extension
Source - Bye Message Proposal

The Bye message is an OPTIONAL message used to inform the 
servent you are connected to that you are closing the connection. 

Servents supporting the Bye message MUST indicate that by sending 
the following header in the handshaking sequence:

        Bye-Packet: 0.1

Servents MUST NOT send Bye messages to hosts that has not indicated 
support using the above header.  Future versions will be backwards 
compatible, so Bye messages MAY also be sent to hosts providing the 
above header with a later version number.

A Bye packet MUST be sent with TTL=1 (to avoid accidental propagation
by an unaware servent), and hops=0 (of course).

A servent receiving a Bye message MUST close he connection 
immediately. The servent that sent the packet MUST wait a few 
seconds for the remote host to close the connection before closing 
it.  Other data MUST NOT be sent after the Bye message.  Make sure 
any send queues are cleared. 

The servent that sent by Bye message MAY also call shutdown() with 
'how' set to 1 after sending the Bye message, partially closing the 
connection.  Doing a full close() immediately after sending the Bye 
messages would prevent the remote host from possibly seeing the Bye 
message.

After sending the Bye message, and during the "grace period" when
we don't immediately close the connection, the servent MUST read
all incoming messages, and drop them unless they are Query Hits
or Push, which MAY still be forwarded (it would be nice to the
network).  The connection will be closed as soon as the servent
gets an EOF condition when reading, or when the "grace period"
expires.

A Bye message has the following fields:
Bytes:  Description:

0-1     Code. The presence of the Code allows for automated processing
        of the message, and the regular SMTP classification of error 
        code ranges should apply. Of particular interests are the 
        200..299, 400..499 and 500..599 ranges.
        Here is the general classification ("User" here refers to the 
        remote node that we are disconnecting from):

        2xx     The User did nothing wrong, but the servent chose to 
                close the connection: it is either exiting normally 
                (200), or the local manager of the servent requested 
                an explicit close of the connection (201).

        4xx     The User did something wrong, as far as the servent is
                concerned. It can send packets deemed too big (400), 
                too many duplicate messages (401), relay improper 
                queries (402), relay messages deemed excessively long-
                lived [hop+TTL > max] (403), send too many unknown 
                messages (404), the node reached its inactivity 
                timeout (405), it failed to reply to a ping with TTL=1
                (406), or it is not sharing enough (407).

        5xx     The servent noticed an error, but it is an "internal" 
                one. It can be an I/O error or other bad error (500), 
                a protocol desynchronization (501), the send queue 
                became full (502).

2-      NULL-terminated Description String. The format of the String 
        is the following ( refers to "\r" and  to "\n"):

                Error message, as descriptive as possible

        or optionally, something more qualified, with HTTP-like 
        headers giving out more information:

                Error message, as descriptive as possible
                Server: some server/version
                X-Gnutella-XXX: some specific Gnutella header
                for instance telling the host about alternate
                nodes it could connect to
                

        The presence of a  at the end of message indicates 
        that HTTP-like headers are present.  The absence of any 
         indicates that the short error message form was used.

        Unless circumstances making that impossible (urgent 
        disconnection due to a memory fault), the HTTP-like headers 
        version SHOULD be used, with at least a Server: header, 
        allowing better tracing and debugging.

For further information about the Bye message, please refer to the
original documentation:
Bye proposal, located at:
http://rfc-gnutella.sourceforge.net/src/bye.html

 

 

 

Home :: Developer :: Press :: Research :: Servents

SourceForge.net Logo