PIMP

Protocol Specification

Version 0.1

Overview

Each node will maintain several active connections.  The exact number is not specified by the protocol, and should ideally be configurable by the user.  Normal user nodes probably will typically maintain between 5 and 15 active connections.  Nodes serving primarily as routers will maintain many more active connections.

The network is based on passing messages back and forth.  It is important to note that these messages are not necesarily the actual instant messages sent by users, but rather the equivalent of packets in TCP/IP.  Each message type has slightly different routing procedures, but all follow a typical pattern.  When a node receives a message, it first checks to see if message has reached its proper desination.  If so, the node processes the message accordingly.  Otherwise, the node checks its active connections and forwards the packet on to the node connected to this node whose routing key is "closest" to the destination of the message.  In the case of a message addressed to the broadcast key, the node should both process the node, and then forward the message out all of its active connections.  In each messag header there is a Global Unique Identifier (GUID) and a number indicating the message's Time To Live (TTL).  Each node maintains a list of recently seen GUID's.  When a node receives a message, it should drop the message if either the GUID has been seen before or the TTL is zero.  When forwarding the message, TTL should be decremented by one.  There is a possibility that the randomly generated GUID's will be repeated, but this should be a rare enough occurence to not disrupt the network too badly.

Messages

If a node encounters a message of a type it does not recognize, it should simply forward the entire message on toward its destination.  This allows the protocol to support new types of messages without needing all nodes to support them.

Header

Total Message Header Size:  88 bytes.

Types

Payload:
ProtocolID - null-terminated string of bytes describing the protocol.  ex: "tcp"
Address - null-terminated string of bytes describing all information needed to connect to this node over the givern protocol.  For the TCP/IP protocol this could be and IP address and port, such as "192.168.0.1:7296", or a domain name and port, "pimpnode.mydomain.com:7296".
Description:
This message is used to give other nodes the information needed to establish a direct connection with this node.  All nodes that come in contact with this message may look at the contents and optionally update their routing tables.  This message is routed otherwise normally.

Payload:
none.
Description:
The destination of this message should respond with an ANNOUNCE.  This message is primarily used to establish shorter paths to a given node.

Payload:
Hops - 2 hex digits describing the number of nodes this message has visited thus far.
Description:
What good would a network be without ping?  This, in combination with PONG, allows nodes to determine their distance from a certain node, and also to determine latency and other network statistics.

Route this message normally, except increment Hops by 1 before forwarding it.

Payload:
toHops - 2 hex digits describing the number of nodes the PING that caused this message visited on the way to its destination.
fromHops - 2 hex digits describing the number of nodes this message
Description:
This message is a response to PING.  It carries both the number of Hops to and from the node, since this number may be different.  Route like PING, incrementing fromHops at each node.

Payload:
Message - null terminated string containing the encrypted IM that the user sent to the given user.
Description:
This message passes actual instant messages through the network.  Route normally.

Payload:
A set of query strings.  The exact number is not known, so the node should continue reading until it has read the Payload Size number of bytes.  Query strings have this form:
"field=value"
Description:
This allows nodes to find new people to chat with based on certain directory info, such as name, age, location, language, etc.  This will almost always be addressed to the broadcast key.  If the destination node meets the criteria, it should respond with an ANNOUNCE, and optionally a DIRECTORY_INFO.  This message is routed normally.

Payload:
none.
Description:
This allows a node to retrieve directory info about another connected user.  It is routed normally, and the destination should respond with a DIRECTORY_INFO message, although it may choose not too depending on the user's privacy settings.

Payload:
A set of info strings in the same form as the query strings from QUERY.
Description:
Normal Routing.  This message contains directory info such as phone number, age, name, language, etc.

Payload:
none
Description:
Route this normally.  The destination should respond with a STATUS.

Payload:
A string describing the user's current status (away, online, out to lunch, etc.). 
Description:
Normal routing.  This message is a response to STATUS_REQUEST.

Cryptography