User:Astronouth7303/SubIM

This describes the protocol used by SubIM.

SubIM uses UDP/IPv4 multicast for communication. Because of this, there is no need for servers, either manual or automatic. If you want something that has full IM features, use Bonjour.

The protocol is a simple message-broadcast approach. All integers are in network byte order (ie big endian) and all strings are in UTF-8.

The basic packet is:   ... The number of arguments is determined by the actual command and the length of the packet (I don't yet provide for packet splitting).
 *  is an unsigned 16-bit integer telling you the command/type of packet
 *  is a counted blob: an unsigned 32-bit integer (the length) followed by the data. The data is usually an UTF-8 string, but you may send binary data as well, depending on the command.
 * ... is more 's.

The first  is the name of the user/host that is sending the command.

The current implementation will throw away data instead of reading an incomplete argument.

There is no protocol initialization. The client simply has to bootstrap its connection (eg subscribe to the multicast group) and it may send any packet at any time.

There are currently 4 commands:

0 - CMD_MESSAGE
0   The given user has sent a message to the chat.

By convention, messages starting with "/me" are action messages a la IRC. The client may choose to handle these (or other specially formatted messages) specially.

Note that it is valid to send a CMD_MESSAGE without ever sending or handling any other commands.

1 - CMD_USER_JOIN
1  This message indicates that a user is present in the chat and is actively listening. It should be sent on initialization and in response to a CMD_LIST_USERS.

2 - CMD_USER_PART
2  This message indicates that a user is leaving and will no longer receive messages, although the exact timing between when this message is sent and when the client ceases to receive messages is immaterial. A client should send this when exiting.

3 - CMD_LIST_USERS
3  This is a request for the current user list. A client sends this when it wants to update its list of currently listening clients. Upon receiving this, a CMD_USER_JOIN should be sent.

4 - CMD_APP_MESSAGE
4    Similar to CMD_MESSAGE. To be used between applications for syncronization and such, in an easily extensible way.

It is suggested that the MSG parameter starts with a command name, followed by a space, followed by additional data, and that simple data (like numbers) be converted to string form.

Other commands
Any command not understood by a particular client may be safely ignored. Vendors are required to make a best effort to not break the protocol outlined in this document with proprietary commands. (eg, a proprietary CMD_CHANGE_ENCODING would not be allowed because clients that didn't implement this would then receive garbage after the encoding change.)

On nicks/user names/host names
There is no assurance that the user name one client uses will be unique.

A client should make decent efforts to make sure its user name is unique.

Proprietary Commands
The 8 most significant bits in the command number (bit mask 0xFF00) may be used as a vendor identifier, and then other clients may implement proprietary commands, as long as they fit within the constructs set out in this document. Vendor identifiers 0x00-0x0F are reserved.