World's Shortest P2P App: 15 Lines

soren.harward writes "The New Scientist has an article about TinyP2P, the world's smallest P2P app. It's 15 lines of Python code brought to us by Edward Felten, CS Professor at Princeton and outspoken supporter of the digital rights the Slashdot community holds so dear. He wrote the program as a proof-of-concept that P2P apps are really easy to write, don't have to be complicated, and thus banning them (a la the INDUCE Act) is pointless and silly."

Reported last month

[joeldixon66]

The 15 line P2P has been mentioned before [slashdot.org] by Slashdot - but the New Scientist article wasn't mentioned last time (as it hadn't yet been written).

The last article also mentioned the 9 line Molestar written in Perl - which is now 6 lines [sooke.bc.ca].

A more legible version of tinyp2p.py

[dstone]

Code is left intact, but here is the whitespace massaged into a more widely-accepted (and readable) convention. You see, Python isn't -that- sensitive to whitespace! ;-)

# tinyp2p.py 1.0 (documentation at http://freedom-to-tinker.com/tinyp2p.html)

impo rt sys, os, SimpleXMLRPCServer, xmlrpclib, re, hmac # (C) 2004, E.W. Felten

ar, pw, res = (
sys.argv,
lambda u:hmac.new(sys.argv[1], u).hexdigest(),
re.search)
pxy, xs = (
xmlrpclib.ServerProxy,
SimpleXMLRPCServer.SimpleXMLRPCServer)

def ls(p=""):
return filter(
lambda n: (p == "") or res(p, n),
os.listdir(os.getcwd()))

if ar[2] != "client": # license: http://creativecommons.org/licenses/by-nc-sa/2.0
myU, prs, srv = (
"http://"+ar[3]+":"+ar[4],
ar[5:],
lambda x:x.serve_forever())

def pr(x=[]):
return ([(y in prs) or prs.append(y) for y in x] or 1) and prs

def c(n):
return ((lambda f: (f.read(), f.close()))(file(n)))[0]

f = lambda p, n, a: \
(p == pw(myU)) and \
(((n == 0) and pr(a)) or ((n == 1) and [ls(a)]) or c(a))

def aug(u):
return ((u == myU) and pr()) or pr(pxy(u).f(pw(u), 0, pr([myU])))

pr() and [aug(s) for s in aug(pr()[0])]

(lambda sv: sv.register_function(f, "f") or
srv(sv))(xs((ar[3], int(ar[4]))))

for url in pxy(ar[3]).f(pw(ar[3]), 0, []):
for fn in filter(lambda n:
not n in ls(),
(pxy(url).f(pw(url), 1, ar[4]))[0]):
(lambda fi: fi.write(pxy(url).f(pw(url), 2, fn)) or
fi.close())(file(fn, "wc"))

Re: Libraries

[dubhead]

The point is, these are standard Python libs.
You don't need to install external third-party libraries for this app.

Re:bet i could write a 15 line

[realdpk]

World's Shortest P2P App: 15 lines [slashdot.org] just over the middle of the page.

Re:bet i could write a 15 line

[Anonymous Luddite]

>> excluding libraries.

There's the important part, I think. Any measure of a program's simplicity based on how many "lines" it is fails to take into account the level of abstraction the language itself provides. I mean how many instructions are called with those 15 lines?

Simple to program != simple program

Re:bet i could write a 15 line

[EnronHaliburton2004]

./ subscribers can preview articles.

I was a subscriber at one point, and I submitted emails when I noticed a duplicate article in the queue, but the duplicate articles were rarely ever removed, and email to "daddypants" frequently bounced.

You missed the point.

[raehl]

The point isn't how trivial (or not) a complete P2P solution is.

The point is that the DIFFERENCE between a networking application that has nothing to do with P2P and a P2P application is 15 lines. Thus, if you write a law that "bans something that allows peer-to-peer file sharing", you've probably just banned the standard distribution of Python since, being only 15 lines short of being a full P2P app, it pretty much allows peer to peer file sharing.

Re:How does this prove anything?

[BobPaul]

However, if that little app becomes as popular as Kazaa or BitTorrent, you can bet they will be gunning for your program; they won't care if it is 15 lines or 150000 lines.

And then as soon as they start gunning for your program, 30 others will pop up and at least 5 of them will become just as popular as yours was, thus making it pointless to have gunned down the initial program; you just made the problem worse.

Quoting the author of TinyP2P
"P2P can be simple and written very quickly, so to try to ban or prevent the technology is not feasible."

Re:Python?

[tepples]

The point was to show how easily something of dubious legality can be made from parts considered legitimate, that SimpleXMLRPCServer and xmlrpclib are 15 lines away from actually being p2p_lib, so if legislators wanted to ban p2p_lib, they'd have to ban SimpleXMLRPCServer and xmlrpclib too. MoleSter [sooke.bc.ca] goes even deeper, threatening that the Perl interpreter is under half a kilobyte away from being a P2P app as well.

Re:How does this prove anything?

[Coryoth]

Does anyone want to enlighten me as to how a 15 line P2P app means that it is pointless and silly to ban them?

The point is that a ban would be ridiculously hard to enforce as pretty much anyone could write a new P2P app, which could quickly rise to popularity. You'd be fighting an endless battle with no hop of victory unless you start putting serious restrictions on compilers etc. at which stage... well...

Jedidiah.

Re:Reported last month

[shellbeach]

Molestar uses a very loose defintion of "lines" ... So as far as line count is concerned TinyP2P is around half the size as Molestar.

No. Perhaps you should have had a look at the TinyP2P web site, which defines a line as follows: "Each line has 80 characters or fewer."

If you really want to compare sizes though, compare the number of characters: TinyP2P has 951 non-whitespace characters; Molster has 436. And the author of Molster also makes the point that almost all the P2P work of TinyP2P is done by an external library. Have a look here [sooke.bc.ca] for more of the author's thoughts on the matter of sizes - they're quite interesting.

Re:1 line?

[Anonymous Coward]

Not really. I don't want to be an ass, but Python does have the semicolon; it's just only needed when you explictly want to do more than one statement in a line (like Visual Basic has the ":" separator).

You're right in a thing: TinyP2P does not use any semicolons, but it's still hard to define how many lines exactly it has. Lines 11-13 represent a single line (which was split to conform to the 80-characters-per-line limit), yet it abuses so much of functional programming and multiple variable assignment that I wouldn't say it's a single line (in the sense of a line being a single instruction with one or more auxiliar operations).

For instance, "x, y = 1, 2" defines two variables at the same time. In standard algorithmic notation (aswell as in most languages), this would be two lines, but Python has a special syntax to do two things practically at the same time. Should we still count that as a single line?

Then there's the 11-13 combo, where three lines represent what would normally be two (as "def aug(u):" should be in a separate line from the rest), and create a lambda function inside the aug function while using the list comprehension syntatic sugar to fit a whole loop (which would normally be a couple lines long) into that single return instruction.

IMO the line counting in this code is just bullshit; Python has too many shortcuts to strive from the standard algorithmic code line, making the competition unfair. And if we get into bytes used, Python is too verbose (as for the logical operators which use keywords instead of symbols and the need of whitespace) to compete with Perl and other more compact languages.

Re:Reported last month

[Punboy]

Um, sorry but there are no ';' anywhere in the program. It's python, we don't need them unless we are stating multiple code "lines" in a single ASCII line. Perhaps you were referring to the commas, which were not specifying separate strings, but were instead specifying the list of modules to import. Do you not know how to read python code? Or would this seriously take one separate line for each module, thus showing Python is far superior in that aspect?

Re:Perl golf goes by the byte

[uhlume]

This argument is either sophistry or stupidity. Perl and python are both interpreted HLLs (although both can also be compiled), so your "466 bytes" of source code is no more intrinsically meaningful a measure than the number of lines in either program: the relationship between bytes of source code and bytes of machine language in this case isn't even in the remote vicinity of 1:1, nor do I know of any simple means to compare the efficiency of perl and python in terms of size of bytecode to size of source code -- or for that matter the runtime overhead incurred by either interpreter.