Slashdot Mirror
Who is Still Using FSP?
orangesquid asks: "So what on earth has happened to FSP, the original 'underground filesharing' system? I know it dried up a long time ago, but most old protocols still tend to have a few odd users (gopher, finger, etc.). However, I haven't found a single FSP site out there that still works. Googling is difficult, because all of the search hits are dated 1996 or earlier, and none of them are accurate. Is FSP still around at all? What are people using it for now?"
And it's a good thing too. Contrary to what the FSP FAQ says, FTP is a better solution, especially with resume. But an even better protocol is SFTP. That's the future as P2P is about to be litigated out of existence.
FSP was popular because you could setup sites in your home directory, and run the daemon without root privs.FSP at the time was "important" for the role it temporarily played. It allowed people to 'casually' serve and retrieve files without needing a lot of infrastructure.
Back when FSP was 'hot', lots of people didn't have Linux servers laying around, or root access, or lots of bandwidth, or p2p gui tools. They had FTP which was a pain to setup in your home directory and sometimes wasn't configurable to non-priv ports, they had TFTP which didn't allow for any authentication.
So, while you bring up some interesting points about why FSP is obviated, since you weren't around when it was 'hot', you may lack the perspective to know why it was at one point useful.
If anything, P2P has really obviated FSP, not Rsync, SCP or SFTP.
Rsync, SCP, and SFTP obviate FTP, but not FTP-SSL..
</historylesson>
Besides, who ever heard of an 'public underground rsync site' ? :)
http://www.remix.net/
I used to use FSP. I even hacked the source to dramatically shorten the time delay it waits between sending requests for data, to get faster service :)
There were 2 main reasons to use FSP:
1) It used UDP, not TCP. Many monitoring/logging tools and firewalls back in the day only really had a tight control on TCP. Using UDP was a good way to slip under the wire.
2) It deliberately kept its data rate very small. Something on the order of 2K per second. Even with a hacked client, the server simply wouldn't send data any faster than a certain cutoff point, and ignored any requests that came in faster than that. This data rate throttling was done, again, to help stay under the radar. Many sites were detected only because a huge upward spike in consumed bandwidth was noticed. Using FSP, a site could stay up for a much longer period of time before being caught and deleted.
Nowadays, we all have great P2P applications to make good use of UDP, and bandwidth usage is usually adjustable on them, so the main reasons to use FSP have gone away. Good riddance, I say, as it was truly a terrible protocol (think of XMODEM over IP)!
Dr. Demento On The 'Net!
sftp is little more than an additional layer ontop of ssh (much like scp, which is also file transfer through an ssh tunnel). It still comunicates ith ssl to to an ssh daemon.
...", and, bang, there you go: it's like "rsync mode for sftp".
Since you need to have ssh set up, anyways, you could try tunneling rsync through ssh. Just "rsync -e ssh
All told, though, I don't really know that this is the solution for safe file sharing, though. This is just a way to do file *transfer* well. At least as important a part of file sharing is being able to locate files. That's also where a lot of the danger to the file-sharer comes in: advertising which files he/she has to share.
:Wq
Not an editor command: Wq
My guess is that someone at Microsoft is waiting for people to forget about it so that they can re-introduce and patent the embraced, extended version for patch downloads.
Microsoft already has a new technique for downloading things. It's far smarter than most other transfer methods, since it can sense in real time how much bandwidth you need interactively and adjust its speed to only use the spare capacity.