Home

Main
FSP Servers
FSP Software
FSP Downloads

FSP project
FSP Team
Testers needed
Open tasks
Wizards vs CSH

Mailing lists
Bug Tracker

FSP Documents
Purpose
History
Articles
Today
Future
INFO
FAQ Old | New
FSP Protocol
Quotes

FSP suite
Browse Code
Copyright
Changelog
TODO
Open Hub page

Java library
Browse Code
API
READ.ME
Changelog
Open Hub Page

FSP C library
Browse Code
README
NEWS
Changes
TODO
Open Hub page

FSP proxy
Browse Code
READ.ME
Changelog

PyFSP
Browse Code

FSP entry in
GNU dir
Wikipedia

My projects
FSP Client
Download Machine
Smart Cache
SC Loader
Old programs

SF Logo

FSP today

FSP is UDP based protocol. This is a feature, not a bug. There are 2 widely used TCP protocols for file transfers: HTTP and FTP - and there is no need to develop a new one.

FSP in the production area

In production area today, FSP is most used in wireless networking, area of embedded devices follows. Using FSP in wireless trunk networks is much more popular than FSP in embedded devices.

Wireless networks

FSP uses UDP datagrams and it is reliable even when there is high number of packet loss. It is usable on WiFi network with 60% packet loss where TCP is out of play. It also good for amateur packet radio network, because 5,10,15,30 minutes lags are not uncommon there. FSP can nicely recover from lags and do not have slow recover like TCP.

Embedded devices

FSP protocol is very easy to implement; protocol core has just slightly more than one page of C code. It is ideal for use in embedded devices for file-transfer tasks, like firmware downloading over serial wire or over Internet.

Because of its simplicity, there is a little chance to writing buggy implementation. Because entire session is managed by client, firmware updates can be more robust. In FSP there are no complicated things likes CRC-16 computations, so it is easy to implement it in microcontrolers in 8-bit CPU.

FSP protocol can be used as wire-protocol even without using any layer 2 stuff. It operates in degraded mode only with extra features disabled.

Replacement for tftp booting protocol

FSP can be used as replacement for tftp boot protocol. FSP is more than two times faster than TFTP, because FSP packet can carry on ethernet 1460 bytes of payload. TFTP have standard block size of 512 bytes, but extensions to the TFTP protocol allows bigger packets also. Not all tftp servers supports them.

FSP is much easier to implement than TFTP, about 2 pages of C code is everything what you need to write. Because entire session is managed by client, FSP is much more reliable on busy networks. Mission critical applications like money tellers machines benefits from using FSP over TFTP for booting.

FSP have features than tftp. For example FSP has directory listings while tftp don’t. Other advantage is that FSP allows random access to files, can open more than one file at the moment and can query file size/date.

Stealth features

UDP ports are not often port scanned today (well except probes for NetBios port). Nobody notice that you are running a fsp server. Since fsp is not widely used today very few people will detect correct type of service running on found port.

Firewall piercing

FSP uses UDP which is unnoticed by many firewalls. FSP server runs on 21 port by default which can be allowed in default firewall configuration because FTP runs on the same port. If you move your FSP server to port 53 (dns) or 80 (http), even strictly configured firewall can be worked around. FSP packets do not contains IP address inside - no special NAT configuration is needed.

Overloaded lines

Where there is no free bandwidth left, TCP protocol in many cases gets unresponsive and connection timeouts after ‘fast start’; so you can get reliably only short files < window size. TCP has also other problem on busy lines - it delivers quite a large amount of duplicate data over network (about 20-30%), which makes things even worse. Last problem with TCP is that after packet drops goes over 10 percent, TCP can not handle it.

Overloaded sites

FSP was always strong in this area. Since most overloaded sites are sites with illegal content, FSP has got a bad name in the past as ‘underground file sharing protocol’. FSP is also good for keeping lamers out because they do not know how to get in (Why my FTP do not works?).

Bandwidth friendly downloads

Everybody knows that. If you have a slow line, download makes all things to crawl. Interactive sessions like ssh are no-longer interactive and web browsing is slow. Background fsp downloads are bandwith friendly and you can still work in ssh without problem. FSP eats about 1/3 of bandwidth used by TCP - based protocols.

Sharing your files

You want to share large data files (movies, ISO images) on slow lines or just do not want to waste your valuable bandwidth. FSP is Ideal for sharing files on modem line and still be able to browse at good speed. If you have on 56K modem and want to share your files by FTP you must first limit access to only 3 or 2 users and even then TCP will nicely eat your bandwidth. FSP do not have this problem, it works nicely without limiting number of users, so everybody can browse and download.

Quicker directory listings

FSP directory listings are very fast when compared to FTP or HTTP because FSP do not need to establish connection. Getting directory listing from FSP server are just 2 IP packets.

Slower downloads

Another nice feature is that downloads are about 2-3 times slower than HTTP/FTP because it has only one packet flying in network. Downloads do not needs to be fast because downloading is not interactive task; better to have free bandwidth available for web browsing instead. Because TCP based protocols are more bandwidth aggresive, they will put FSP download into ‘background’.

Lightweight service

FSP server is a very lightweight service. It uses almost zero resources. fspd running on P233 servicing 6 clients uses about 2% of CPU, 1MB RAM and 60 kBits of bandwidth. FSPD has builtin trafic shaping, so you can set any bandwidth limit.