Communication Groups
All communication in Infinote is organized in communication groups. A communication group is a group of hosts which are able to send messages to each other or to the whole group. The idea behind this concept is to decouple the messages defined by the protocol from the transport layer used to transmit the messages between hosts. The core Infinote protocol just specifies a set of XML messages that need to be understood by hosts. How these messages are transmitted is up to the communication group, or more specifically, the communication method of the group.
Before elaborating more on this, let us introduce the concept of a network in Infinote terminology. A network is an object which connects multiple hosts and allows them to exchange XML messages. It is expected, that each host has a unique identifier on a given network. For example, TCP/IP can serve as a network where an IP address/port number pair can be used as a host's ID. Another example can be a Jabber network where an account's JID can be used as the ID. It is also expected that hosts on different networks can not talk to each other, however a host may be present on multiple networks.
Each communication group is uniquely identified by a name and the network ID of the publisher of the group. This means that every group is published by a certain host. The group can be published on all the networks that host is on. In this case, the publisher is responsible for relaying messages between networks. This also means that if the publisher goes down, there is no way for group members in a certain network to still reach the members in a different network: The group is "split" into a different group on each network. There is currently no possibility for another group member to take over the responsibility to relay messages between networks if it happens to be on more than one network, but such functionality can be added later. Note that also, when the publisher goes down, the group can still continue to exist on a single network only if the communication method allows. This is why, when publishing a new group, a host should always make sure to choose a unique name for the new group. Even if it dropped the group earlier there might still be other hosts which continue to use it. There is one exception to this rule which affects the initial group, see below in the corresponding section for details.
Finally, the communication within a group on a network is controlled by a communication method. All group members need to use the same communication method, so when joining a group they need to know what method is being used. The method defines exactly how XML messages are transferred via the network. However, a group may use different methods on different networks. Some methods may not even be available on a certain network. All it needs to do is to fulfill the following requirements:
- Reliability: It needs to make sure that, when a host is sending a message, the message will arrive at the destination. If the underlying transport (such as TCP or UDP) does not guarantee reliability, then it needs to take care of that itself by acknowledging and resending messages if needed.
- Ordering: It needs to guarantee that messages arrive in the same order they have been sent. Again, if this is not already guaranteed by whatever transport the method uses it needs to make sure itself that messages are reported to the upper layer in order, for example, by adding sequence numbers to messages and holding back messages if an earlier sent message has not yet arrived.
- Multicasting: It needs to be able to send messages both to single group members to which a host has a direct connection and to all of the group. This is called the scope of a message, and it can be either point-to-point (to a single host only) or group (to all group members).
Given these preconditions the higher level of the Infinote protocol can be specified in a general way, not depending on how the messages are actually transported. This provides a great flexibility and applicability.
Upon reception of a message, the message is processed and the so-called scope of the message is decided. The scope of the message can be either "point-to-point", meaning the message is sent from one group member to another one, or "group", in which case the message is sent to the whole group. If the message has scope "group", then the communication method needs to make sure that all group members receive the message, for example, if the host is the publisher of the group, then it needs to relay the message to group members of other networks then the one of the connection from which the message comes from. It is suggested that, when an error occurs during processing of a message, then the message is only treated as a "point-to-point" one, even if it would have "group" scope otherwise.
Defined networks
The following networks are currently defined:
| Network | Description |
|---|---|
| tcp/ip | Connections are established via TCP/IP, then a XMPP stream is opened, as described by RFC 3920. After that, infinote's XML messages are exchanged as they are. IP address and port number in standard dots notation, i.e. 127.0.0.1:6523 for IPv4 or [::1]:6523 for IPv6 are used as host IDs. Note that actually this is not unique since, if hosts are behind a NAT, then hosts from outside might see a different IP address than hosts from within. This is why only the "central" method (see below) is currently supported for tcp/ip connections. |
Another possible network, which could be added later, would be communication via a Jabber server.
Communication Methods
The following communication methods are currently defined. Each communication method is identified by its name. A communication method can be defined for all networks, or for a single network only. In the latter case, it's name must be qualified with the network name in the form "network-name::method-name".
| Method | Description |
|---|---|
| central | The central method is a very simple communication method which is supported for all networks. Each host maintains only a single connection to the publisher, and the publisher maintains a connection to each other host. Hosts can only send messages to the publisher, and if the message is a group message, then the publisher relays the message to all other hosts. Therefore, if the publishing host goes down, no communication is possible anymore within the group. An XML message being sent with the central method is sent as a child of the top-level <group/> message. On the top-level, only <group> are allowed. They have two attributes namely "name" and "publisher", which identify the group the message belongs to. "name" contains the group name and "publisher" the network ID of the host that published the group. "publisher" can also be one of "me" or "you" in which case the sending or receiving host is referred to as the group publisher, respectively. If no publisher is given, then "me" is assumed. Example 1: <group name="InfDirectory" publisher="you"> <more-content /> </group>Example 2: <group name="InfDirectory" publisher="84.241.121.83:6523"> <more-content /> </group> |
Other communication methods can be added later. Examples are "peer-to-peer" (either in a way where each client is guaranteed to be able to connect to each other client, which is a reasonable assumption on a Jabber network, or in a "failsafe" way in which it is not guaranteed that each host can directly connect to each other host, such as in a TCP/IP environment with NAT being involved), or "jabber::groupchat" where group messages are relayed in a jabber multi user chatroom. "udp::multicast" might be another interesting option.
Initial group
After connecting to a server, each client has implicitly joined a group with name "InfDirectory", published by the server. The group always uses the "central" method and is thus available on all networks. Also, since it uses the "central" method, the group does no longer exist once the server goes down. Therefore it is safe to have the restarted server's initial group also named "InfDirectory".
Enhanced Child Text
Some XML nodes allow child text which contains <uchar codepoint="uuuu" /> children, with uuuu being a unicode character point in decimal notation. This is to be interpreted as if the child text contained the given unicode character at the position of the <uchar /> node. This allows transmission of characters that would otherwise be invalid XML, such as null bytes. The protocol specification explicitly stated whether a message allows such enhanced child text or not.