User:Jacek Antonelli/Plugin System/Networking

Local Sockets Only
The viewer should be configured to use local, UNIX sockets only. The reasons for this are:


 * 1) UNIX sockets are very fast and efficient, especially on Linux and MacOS X.
 * 2) It simplifies things on the viewer side to support only one sockets method.
 * 3) Restricting connections to local limits the opportunity for security exploits by remote attackers.

Of course, it's not hard to imagine a scenario where one would want to have a plugin connect over the Internet or LAN. But, that can be better achieved via a "bridge" plugin which accepts incoming remote requests and feeds them to the viewer via local sockets. This provides the opportunity for the plugin to encrypt, compress, and/or validate the networked communications in ways that we could not anticipate when programming the viewer.

Coordinating Sockets
Each instance of the viewer will have its own socket file, so that it can run its own plugins separately. When the viewer starts, it would check for an available socket ; if that's already in use, it would try ,   and so on. Once it finds an available socket path, it starts listening for incoming connections.

Then, when the viewer launches a plugin, it passes the path to the socket as an argument to the plugin. The plugin is then responsible for establishing a connection on that socket. That means a requirement of the plugin script is that it check its arguments and use the provided path. Once connected, the plugin and viewer do some handshaking, and then can send messages back and forth.

Counted Message Length
Each message that is sent is prefixed with a 4-byte unsigned binary integer in network order specifying the number of message bytes following.

So, if the message was, the message length is 33 bytes. Expressed as a 4-byte binary integer in network order, the number 33 is. So, the full text that would be sent over sockets for this message is:

\0\0\0!["request", "GetProps", "entity"]