Dr. Edward Felten recently posted a piece of code called TinyP2P, which demonstrates how easy it is to create a peer-to-peer filesharing application by doing it in just 15 lines of Python.  However, TinyP2P uses a ready-made XMLRPC server library, which seems to me to be taking the easy way out.  Here's my response:  MoleSter, a non-trivial filesharing application in 6 lines of Perl, using no protocol library more sophisticated than TCP.

NEW:  Thanks to a bunch of suggestions from Rob Kinyon, as well as more testing and protocol work of my own, MoleSter is now (version 0.0.4) down to 6 lines and 466 bytes, and works better than ever before.  Peer discovery now happens semi-automatically, so you need to do fewer explicit h/ commands to get linked into the network.

Take a look at the commented and documented source code, or the cryptic and concise version.

Documents in this directory


If people want to be competitive about this, I think some appropriate rules would be as follows:

  • Use whatever language you want
  • It's okay to require invoking the interpreter outside of your byte count (thus, no charge for a "#!" line at the start) but not to use other external utilities that have to be exec()ed, nor infrastructure like shell builtins (unless you're writing it in shell..)
  • No glaring security holes
  • Must have at least some kind of password/lockout/whatever so that if all participants in a network cooperate, they can prevent non-participants from obtaining, inserting, or getting a list of files
  • No protocol libraries above the level of TCP
  • No libraries that aren't in a default install of your compiler/interpreter
  • To qualify as a P2P file sharing application, the user has to be able to connect to a network of peers and download a file (may require knowing the filename) without already knowing the identity of the peer that has the file - thus, must support some means for discovering peers or searching for files

This program is called MoleSter because it's small and furtive, like a mole, and "-ster" is a traditional suffix for filesharing programs.  It rhymes with "pollster"; don't pronounce it as three syllables.  Every time I look at the word "molester" my brain tries to parse it as "mole-ster" instead of the agentive of "to molest", and now I have an excuse to name a piece of software MoleSter, so I'm going to use it.

Please note that this code is quite inefficient with regard to bandwidth and memory.  It is a proof of concept only.  I recommend only using it for text files up to a few tens of kilobytes; if you start using it for multi-megabyte multimedia files, software distributions, etc., you'll run out of memory and overload your connection.

This ought to go without saying, but I'll nonetheless repeat Dr. Felten's disclaimer, which goes for me as well:

My goal in creating this program is not to facilitate copyright infringement.  I do not condone copyright infringement.  Nothing about the program's design is optimized for the sharing of infringing files.  The program is useful mainly as a proof of concept.  A more practical program would be faster, more secure, and more resilient against failure.  But that would require a few more lines of code!


Can we sell T-shirts with this code on them, get tattoos of it, etc.? Go nuts, it's public domain.  But please don't lead your customers to believe that I'm getting a cut of the proceeds unless you give me one.  Also, keep an eye on this page for new versions, and test the code before you put it on a T-shirt.  It would really suck to go around wearing a T-shirt printed with code that doesn't work.  Other geeks would laugh and point.  Of course, a tattoo of buggy code would be even worse.

This isn't a useful P2P application because of (efficiency, security, searching, user-friendliness, redundancy, poor documentation, etc.)! It's not meant to be a useful P2P application.  It's meant to be a fun and educational programming exercise.

Trying to write very few lines of code is silly, because it would actually be easier to write a longer program. Yes, I know, and I've already written about that in my blog.  But writing ultra-short code is fun even if it's silly.  No other justification is necessary.

Trying to write very few lines of code is silly, because you could just put everything on one line. Not if you demand that lines be 80 characters or less; and if you do demand that (as I do) while also trying to minimize the number of bytes, then breaking the lines becomes an interesting challenge because Perl syntax requires whitespace in some contexts, so you have to arrange things to make the line breaks occur in those places to get the required space and the line break from the same byte.

This isn't a useful P2P application because you need to know the address of the peer! You need to know the address of a peer.  Given one address, the software can find out the addresses of other peers with the "h" command (or implicitly as it receives responses to its other requests) or communicate with peers indirectly with the "f" command.  In this respect it's not unlike BitTorrent - you need a handle into the network to get started.  Please note that TinyP2P (about which I first heard this objection) also has a similar feature.  Both Felten's and my programs are different from FTP and Web servers because our code includes peer discovery.

It isn't very well-obfuscated; I can still read the code! It isn't meant to be obfuscated; it's meant to be concise.  The goal is to do it in very few bytes.  Within that goal, it would actually be nice to make it as readable as possible, although it's a fact that minimal-byte Perl tends to be quite hard to read.

You're using Socket.pm, and it's huge, that's cheating! Since version 0.0.2 MoleSter no longer uses Socket.pm.  As for version 0.0.1, I should have read the fucking code myself before posting the 0.0.1 version of this answer, because I forgot that it actually does use the sockaddr_in packing routine as well as symbolic constants.  I still think that even in 0.0.1 I did better than Felten and Halderman, who imported an entire XMLRPC library.

You're using an operating system, that's cheating! The Zen master says:  you don't need to share files on your computer with no operating system.  Where would you put them?

Are you related to US Supreme Court Justice Antonin Scalia, (or some other famous person with a name equal or similar to "Scala")? No.  The correct spelling of my name is all over this Web site, and according to my own quiz, I'm closest to the Honourable Madam Justice (retired) Claire L'Heureux-Dubé.

Isn't it going to be a career problem for you to have your name linked with the word "molester" (as in the agentive of the verb "to molest") in Google? Try searching my name in Google and see the other things it's already linked with; or even just take a look at the rest of my Web site.  Also, note that the creators of Back Orifice 2000 and UNFUCK.EXE don't seem to have career problems just because of those names.

Won't naming this "MoleSter" give the four-letter organizations ammunition for claiming that file sharers are sexual predators? Since this code isn't really much use for actually sharing multimedia files, I think it's unlikely that they will consider MoleSter a threat worth pursuing.  Opponents of file-sharing software would probably prefer not to draw any attention to the educational points made by MoleSter.

But what if they do, aren't you afraid of getting sued? File sharing as such is perfectly legal in Canada - copyright violation isn't, of course, but I'm not violating any copyrights.  There is even case law to suggest that sharing of commercial music (only music, not other materials) without permission on filesharing networks is legal in Canada, because it's one of the activities paid for by the Blank Media Levy.  The idea is that you already paid for the music when you bought the blank media you're copying it onto, even if you are copying it onto a medium such as a computer hard disk for which the levy rate happens to be zero.  The decision in question is currently under appeal, and there's been one recent relevant decision which I haven't read yet and can't comment on, but you can get more information from my blog commentary on BMG v.  Doe.  Suing me for alleged copyright infringement has already been tried, anyway.

Related pages:


No comments yet.

New comments are disabled, pending transition to new site code.
Copyright 2024 Matthew Skala
Updates to this site: [RSS syndication file]