sbus is simple message bus based on unix domain, sequenced-packet sockets.

Features:
	Support for multi-user buses.
	No support state-keeping in clients.
	Supports all send(2)/recv(2) flags.
	Almost full setsockopt(2)/getsockopt(2)/fcntl(2)/ioctl(2) support:
		No send-time timestamps
		Increasing message size limit may cause problems
	Support for routing keys with wildcards.
	Support for secret communication.

Non-features:
	No IP or cluster support, should be implemented as a separate service.
	No support for overly larged messages, should be implemented at application level.
	No persistence support, should be implemented as a separate service.
	No support for automatic unsubscriptions.
	No support for reply-to keys, should be implemented at application level.
	No support for shared queues, should be implemented as a separate service.
	No file descriptor passing support, not network-compatible, should be
		implemented as a separate service or at application level.
	No support for server-verified credentials, can be implemented at
		application level by using '!.cred.' routing keys.

Routing keys:
	Routing keys are used to filter received messages. A routing key
	may contain any byte, whoever there are three bytes with special
	meaning: '*', '.', and '!'. '*' should not be used in routing keys,
	but only in routing key patterns, it matches until the next '.' or
	end if there are not more '.'s. Additionally if a routing key
	pattern ends with '.' that '.' will match to a '.' and any
	subsequent byte. For example 'a.*.c.' will match 'a.b.c.' and
	'a.b.c.d.e' but not 'a.b.c' or 'a.c.d'. And empty routing key
	pattern shall match everything. The token '!' is reserved, a client
	should never use '!' for any other purpose than specified in the
	protocol, unless it has an other byte than a '.' next to it. The
	server may choose to disconnect a client using '!' in an invalid
	way or simply ignore such messages.

Protocol:
	Communication is done over unix domain, sequenced-packet sockets.
	Each packet is interpreted as a complete message. A packet cannot
	contain multiple message, and a message cannot be split over
	multiple packets. There are 4 types of messages:

	Subscribe:
		Send a routing key pattern to the server for the client.
		The server shall send all messages with matching routing
		keys to this client. The server shall store the key even
		if there is already an identical routing key pattern
		registered for the client.

		Messages of this type shall match the regular expression

			^SUB \([^\x00]*\)\(\x00.*\)\?$

		where \1 is the routing key pattern, \2 is ignored.

	Unsubscribe:
		Tell the server to remove a routing key pattern for the
		client. The server may choose to disconnect the client
		if it sends a routing key pattern that is not registered
		for the client.

		Messages of this type shall match the regular expression

			^UNSUB \([^\x00]*\)\(\x00.*\)\?$

		where \1 is the routing key pattern, \2 is ignored.

	Publish:
		Publish a message on the bus. The server shall send a
		copy of packet to all clients with a matching routing
		key pattern, including the client that sent the packet
		if and only if that client has a matching routing key
		pattern. The server may not send a copy of the packet
		to any clients without a matching routing key pattern.

		Messages of this type shall match the regular expression

			^MSG \([^\x00]*\)\x00\(.*\)$

		where \1 is the routing key for the message and \2
		is the message payload.

	Control message:
		Send a control message to the server. The server may
		also send control message to clients. The server will
		never forward control message it receives, and no
		subscriptions are required to receive the messages.

		Messages of this type shall match the regular expression

			^CMSG \([^\x00]*\)\(\x00\(.*\)\)$

		where \1 is the routing key for the message and \3
		is the message payload. \2 may be om be omitted if
		sent by the client.

Secret messages:
	Routing keys starting with '!.cred.' can only be subscribed to
	by clients with matching credentials. These routing keys look
	match this regular expression

		^!\.cred\.\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\)\.\(.*\)$

	where \1 is the group ID, \2 is the user ID, \3 is the process
	ID, and \4 the rest of routing key which may also use this
	pattern a process it communicates. Client can only subscribe
	to the routing key \1, \2, and \3 match it's credentials.
	If \1, \2, or \3 are empty, they will match the clients it's
	credentials when subscribing. However, the server will not
	accept '*' for \1, \2, or \3, or truncated routing key.s

	However, due to network support, these routing keys may need
	to be prefixed with the credentials for the servers the message
	goes through. This prefix can be retrieved by simply sending an
	empty control message (CMSG) with the routing key '!.cred.prefix'
	and the server will reply with a control message containing prefix
	using this routing key. Note, prefix is probably the empty string,
	as the master server do not need to add its credentials to be
	prefixed. Note, the server will never send control messages, so
	received control message are guaranteed to come from the server.

	Example of how two client can prove their identities to each oter:

		A: Send A's credentials to B.
		B: Send B's credentials with routing key private to A.
		A: Send a random message with routing key private to B.
		B: Send back the message with routing key private to A.