{packet} :=
[ {revision} := {one byte} 0x80, UDP only ]
{length} := {vl-int != 0}
{msg counter} := {one byte}
[ {group name} := {null-terminated string} UDP only ]
{data} := {any binary information}
{msg id} := {group name} {source} {msg counter}
{group name} is not an id. It is a human readable short name for a channel
or an unstructured group of people. This name must only be unique at the
originator's client, since it is used to identify a message. When a message
is directed to the receiving entity itself, the {group name} is simply empty.
The {msg counter} is a number the originator increments for each message sent out, kept for each adressed network object or group. The receiver will keep the count and can therefore soon discover when he has missed a message. He will then request a retransmission of the missing message.
Any network object sets up its own counter of sent messages for each communication partner. A random value is generated each time, when the number reaches the value 0x100, the count inevitably wraps to zero. That is intended and acceptable.
{control msg} :=
[ {revision} := {one byte} 0x80, UDP only ]
{escape} := 0x00
{length of msg} := {vl-int}
{command} := {reply-flag} {7 bits}
[ {arguments} ] := {depending on command}
Only events that have a direct impact on the transport of messages are
treated by MTP control messages, so the event of someone changing his
current nickname is not mentioned here, to name an example.
0x00: AYT # Are you there? Both query and reply according to flag
0x01: QINFO # Reissue header info
0x10: INFO # Header information including TARGET, details below
0x11: TARGET # Destination is {object}
0x##: ACK_TIME # {time} till acknowledgment is sent
0x20: ERR_UNKNOWN # No such {object} defined here
0x30: TEMP_RELOCATION # {object} is currently reachable as {URL}
0x31: PERM_RELOCATION # {object} has permanently moved to {URL}.
0x##: ACK # acknowledgment of received msgs {list of msg-ids}
0x##: OFFLINE # sender is leaving the network
The temporary relocate will be a very common message, as whenever a user
is logged in, his psyc server is likely to inform inquiring users directly
of his current host and port number. A permanent relocate message is
typically generated whenever a user changes home server, or a channel does.
These conditions are handled on this low level, since they will be relevant
to message routing in future revisions of MTP.
AYT requests are answered with AYT + {reply-flag}, so are TARGET and ACK_TIME messages, should the contained TARGETs be available on the other side. Otherwise ERRORs must be issued. A QINFO expects the other side to reply with an INFO.
{TCP hello} :=
{protocol name} := {3 bytes, ASCII: "MTP"}
{MTP revision} := {ASCII representation, '0'}
'\r\n' := CR LF
As the communication between two entities begins, basic information needs
to be exchanged. Whenever a TCP connection is established the caller first
transmits the {TCP hello} which in a human readable tells the callee that
binary MTP protocol is going to follow. The callee may choose to generate
this message immediately, too, or await the caller's. The caller may
directly proceed to send the MTP {header}, which is itself a
{control msg}. The callee may again choose to await the {header} or send
it immediately after link creation, too. This allows the callee to handle
other protocols as HTTP on the same port with PSYC, if it chooses to.
Both send the {TCP hello} and the {header} information in the same format.
When the {header} is sent actively, it is sent without the {reply-flag}
set. When it is sent in reply to a QINFO request, then it is sent
as a reply.
{header} :=
{MTP revision} := {one byte: currently 0x00}
{my object id} := {null-terminated URL}
{target} := {null-terminated URL}
As you can see URLs are not only used by the user interface (client)
programs to open the connection, but they are also used directly as PSYC
object identification scheme.
The "psyc:" URL type currently being the only supported one, can be left out. Hostname information may not be left out, also port information should be provided. Object-names may also be provided, so you can directly start to communicate with a specific object on a server, if it exists.
Commands are not to be integrated into the URL used by the MTP. They must be extracted by the client program and handled on the PSYC layer.