Routing variables

FIXME: _time (or was it _date?) family which typically contain the timestamps of earlier multicast messages need to move into routing as well, since routers need to know if they are retransmitting an earlier packet, or are doing a fresh multicast.

These are the basic variables defined by the routing layer of PSYC. How these variables interact in unicast and multicast packet routing can be read on Spec:Routing.

  • _source - The source entity uniform the packet comes from.
  • _target - The recipient entity.
  • _context - The context (a chatroom, a newsroom, a presence subscription or other group or channel).
  • _source_relay - The original sender of a message. Eg. set to the participants uniform when a group relays messages to it's participants.
  • _source_identity - Contains the uniform of the person entity the _source of the packet is linked to. This is used for example when a client wants to speak for his person entity, e.g. psyc://localhost:-21345 wants to speak in the name of psyc://goodadvice.pages.de/~heldensaga. See also Spec:Person about more details about the semantics.
  • _target_relay - The original target of a message. When a client uses the Identity to which it is linked to as relay to send a message. See the client interface for more information
  • _tag - A tag that should be refered to when this message is replied to or forwarded. The tags can be used to associate replies to their original requests. (Implementations might use callbacks to signal a response to a request).
  • _tag_relay - The original tag of the message this message is a reply to or forward of.

During the process of routing keyword inheritance is not in effect. A _source_relay MUST NOT be treated as if a _source was given. Inheritance is to be applied to routing variables only in the entity layer.

Tagging


The routing variables _tag and _tag_relay are used to implement a special behaviour called Tagging in PSYC.

It is mostly used to map a response back to its request and gives the sender a way to easily figure out which replies were triggered by packets it sent and thus handle responses asynchronously.

When an entity receives a packet and intends to send a response to it, it MUST copy the contents of the _tag variable to the _tag_relay variable of the response.

The contents of _tag is opaque and can be an arbitrary value. It is strongly recommended to generate globally unique ids for tags.

Should the routing layer of any involved router encounter an error while delivering a tagged message and intend to generate an error message, it SHOULD copy the tag to a _tag_relay variable in the error report.