The Snarl Network Protocol (SNP) provides simple access to both local and remote instances of Snarl. It is TCP-based and thus the sending computer need not be running Snarl (or Windows) - so long as it can connect via TCP/IP to a remote computer running Snarl, it will be able to send notifications.
Note: this document refers to the current version of SNP, for previous versions of SNP, see the legacy SNP page.
SNP 3.0 introduces the following benefits over earlier versions of the protocol:
Communication takes place using TCP via either port 9887 or port 5233. Typically it is down to the client to manage the connection and terminate it when no further communication is required, however in some cases Snarl may terminate the connection (due to malformed messages, security concerns, etc.).
Note: To use TCP port 5233, the destination computer must be running Snarl R2.5 or later.
The communication process is as follows:
Callback events and notifications forwarded as the result of a subscription will also be received by the client.
The client may choose to create a new socket for each request, or re-use an existing socket. If the client is expecting to handle callbacks then it should ensure the socket remains open at least until the callback is received. If a client has subscribed for notifications from a remote computer, it must leave the socket open in order to receive notifications sent by the remote computer.
An SNP 3.0 message consists of:
Additionally, the following:
Two types of message are currently defined: requests and responses.
An SNP 3.0 request is sent from a client (which may be Snarl but more likely will part of an application) to computer running Snarl. An SNP 3.0 request consists of:
The header, all request lines, and the terminator must all end with a CR/LF pair.
With no hashing:
With SHA-256 hashing:
id/version is always required and must be "SNP/3.0"; hash_type and cypher_type are optional, however if cypher_type is specified then hash_type must also be specified.
See Security for details of supported hashing and encryption algorithms.
Each action must be on a separate line and there must be at least one action contained within the message (otherwise you'll receive a SNARL_ERROR_BAD_PACKET response).
Actions follow the standard format, however there are some specific points to note:
An SNP 3.0 response is received by a client from Snarl. An SNP 3.0 response consists of:
The header, all content lines, and the terminator all end with a CR/LF pair.
The SNP 3.0 response header is as follows:
A failure response provides the same content as a success response. In some cases, a "hint" line will indicate more specific information about the error that occurred.
Status codes are defined here.
A callback is a specialised type of response message.
Authorisation ensures only applications that share a common secret (in this case, a password) can communicate with Snarl. The password is entered on the remote computer running Snarl and is used in the construction of the key and key hash on the client, consequently it is never transmitted in clear text between the client and remote computer.
Currently, three forms of hashing are supported:
Due to deficiencies identified in both MD5 and SHA-1, it is recommended that SHA-256 should always be used when communication may occur over a WAN or across the Internet in an unsecured channel.
The authorisation type used is determined by the sender and is included in the SNP 3.0 header, along with the key hash and salt value used. A new salt value should be used for each request.
The key hash is computed as follows:
Using a password of "abcdef" and random salt of "1A2B3C4D5E6F" and MD5 and the hashing algorithm:
Resulting SNP 3.0 header:
Subscribing and forwarding achieve a similar end result but are subtly different.
As the name implies, a subscription is an open-ended connection initiated by a client to a known remote computer, both running Snarl. Some examples of subscriptions:
To summarise: a subscription takes place between two instances of Snarl, is initiated by the client computer and remains in place until the client unsubscribes.
Conversely, forwarding is effectively a wrapper for an SNP 3.0 register/notify action pair. Forwarding is still initiated by a client, however it's the client that is wishing to '''send''' notifications to an instance of Snarl, not receive them. The instance of Snarl may be running on the same computer, but more often than not it will be running on a remote computer. The client may use Snarl to send the register/notify message, although it's more likely it will be an application which creates the message itself. Some examples of forwarding:
The subscribe action is documented as part of the Snarl [[Generic_API#subscribe|generic API]]
Subscribe to notifications from all applications:
Subscribe to notifications from only the applications with signatures "foo/bar" and "bar/qux":
Subscribe to notifications from application "foo/bar" and attempt to subscribe to notifications from "wont/work" - the latter request will fail because the password supplied during the initial subscription was not provided:
Note that neither the IP address or the port number of the subscriber are required - these are derived directly from the subscriber's socket in order to avoid IP address spoofing.
Future revisions of the SNP 3.0 specification may allow the subscriber to provide a friendly name that the remote instance of Snarl will display in the subscriber list. The friendly name would be most likely be passed as a message parameter, as follows: