The client mode of Mserv is a well defined way of communicating with the server. There are two modes for client mode operation: COMPUTER and RTCOMPUTER. COMPUTER and RTCOMPUTER feature exactly the same protocol allowing the client to issue commands and receive answers back in return. In addition to this, the RTCOMPUTER clients also receive real-time asynchronous (unrequested) data. This would typically be information such as newly added tracks to the queue, users connecting and disconnecting etc. This way of communicating things as-they-happen alleviates the requirement for the client to poll the server to see what is new.
The protocol is based on a textual line-by-line approach similar to standard protocols such as SMTP, NNTP, HTTP etc.
Mserv uses a TCP stream connection usually on port 4444. The port assigned to a server may however change at the discretion of the system administrator and as such all clients must be able to change the port they connect to at the request of the user.
Once connected you will receive an automatic response, type 200.
You should then issue a USER followed by PASS command, indicating in the PASS command whether you will be accepting real-time data. Read these two command specifications later in this document for further information.
All responses to commands are formatted in the following way:
The response line always begins with a 3-digit response code that indicates what type of response has been generated. Mserv uses an SMTP-style grouping of response code types:
Each code has a message associated with it that is returned by the server on the same line. This message is generated using a language file that the server reads in, and as such, can be any string. This string should not be parsed, but could be displayed to the user.
The file english.lang included with Mserv shows all known codes and what they are used to indicate.
The response data can be any number of lines, even 0. Each line consists of a protocol defined number of elements, each separated with the TAB character. The number of elements is determined by this protocol specification on a command by command basis. Client implementations should always accept more elements than have been specified by this protocol to allow for future expansion. No element may contain the null character (ascii 0), the tab character (ascii 9) or the newline character (ascii 10).
A single dot on it's own ends the response to a command.