• Message Transfer Protocol (MTP) rev.0
  • This is a simple definition of the MTP, which only enables for direct msg transfer via UDP or TCP. No routing of messages is supported in MTP revision 0. However message forwarding, routing and multicasting may also be achieved through the PSYC control layer, although not as efficiently.

    1. MTP data transmission
    2. This is how a packet looks like. Some fields are present in UDP messages only, since when TCP is used, they are specified once via {control msg}.
      {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.

    3. MTP control messages
    4. Control messages are distinguished from data messages by the length info being a zero, which makes no sense for data messages.
      {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.

    5. MTP header info
    6. {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.