FSP protocol is well documented. You can find the latest protocol definition right here http://fsp.sourceforge.net/doc/PROTOCOL.txt or in the source distribution in the "doc" subdirectory.
FSP is datagram-based protocol. FSP protocol itself do not require reliable underlying transport. FSP can operate even without any Layer 2 and Layer 3 transports only with some extra features disabled. FSP can be implemented in all kinds of environments. This makes FSP very suitable for embedded devices area, because it is easier to implement than other transfer protocols like X-Modem.
When used in TCP/IP based networks, UDP is used for transporting of FSP datagrams, this lowers protocol overhead by skipping TCP level, which is not needed, because FSP handles connection management by itself. This method is standardized in Section 5.1.
FSP frames can be packed directly info Ethernet 802.2, USB or GSM frames. Biggest advantage of using FSP in that areas is simplicity. FSP protocol is very simple to implement.
One of interesting parts of underlying network technology used by FSP is how protocol design restrict user from sending more than one packet into network.
FSP uses very simple method: Every packet sent from server to client contains a 16-bit long, pseudo random key. Client needs this key for sending next request to server. Server will ignore requests with wrong key, unless there was no previous activity recorded for client IP address in last 60 seconds.
Server remembers for each IP not only nextkey, but also previous key. When packet's key matches previously stored key -- it is resend from client. Server limits replies to resend packets also. Max. allowed reply rate to resend packets is 1 reply per 3 seconds. This method also allows ignore duplicate requests by server for action which should not be done more than once (for example mkdir).
In each packet sent by client to server is sequence number. Server will echo this number back to the client, when packet is processed. There is no restriction on that number, client can use anything he wants. Primary purpose of this sequence number is possibility to put unique mark on every network packet. Client can use this information and fine-tune its retry algorithm by computing packet loss ratio of network, and duplicate packet rate.
FSP server has its secret keys database divided by client ip address, not by client:port. All requests comming from the same machine must shares the same secret key. This is done for bandwidth protection.
Client must submit a valid key with request. Where there are 2 programs runnings on the client PC and both wants to talk to the same FSPD at once, they must exchange knowledge of this secret key between themselfs. If they don't, only one program can talk to the FSPD, because others do not knows the next session key. They can try to talk but fspd will ignore them. This is kind of client-side multiplexing.
There are several methods how to do this key sharing. Best method is to use semop+shmget, second is to use lockf on file in /tmp. All FSP clients running on the same machine must use the same locking method.
File Service Protocol defines maximum packet size 1024 bytes of data + header. All FSP compatible protocol stacks must support this packet size. Nearly all networks can transfer 1036 bytes long UDP packets. Some networks allows only 512 bytes long UDP (maximal size required by RFC). To use FSP on that networks, fsp clients must be configured to use only 500 bytes of payload.
Because MTU of most networks is about 1500 bytes. It is true, that we can use slightly bigger packets for gaining some speed. FSP server can optionally support larger packet size, but must send them out only on explicit client request.
We have performed some benchmarks and they shows only minor performance increase, about 10-15 percent. Similar testing was performed by HP in RFC 2348.
For bigger performance enhancement we need to use at least 2.5 KB, but packets of that size must be fragmented on most network and fragmenting increases possibility of packet loss.
You can easily add support for FSP v2 protocol into your programs. Currently exists two independend libraries for FSP protocol support and one library is in the work.
First library is called JFSPlib. This is FSP library for Java language.
Second library is called FSPlib. This is FSP library for C language with POSIX-like API.
FSP support for Python PyFSP is currently work in progress. Note: PyFSP uses GPL license, not MIT/X11 like other libraries.
Set FSP server and client to use bigger block size (Section 5.5), decrease server retry timeout to 1 sec, and descrease client delay also. Using this methods, FSP can run about 1.7 faster than before. If you need even higher transfer speed, switch to HTTP protocol.
If your FSP server eats too much bandwidth, the best is to use smaller packets. FSP server has builtin output thruput limiting, you can slow down it in fspd.conf file. Slightly increasing server retry timer also helps.