TinyP2P is a functional peer-to-peer file sharing application, written in fifteen lines of code, in the Python programming language. I wrote TinyP2P to illustrate the difficulty of regulating peer-to-peer applications. Peer-to-peer apps can be very simple, and any moderately skilled programmer can write one, so attempts to ban their creation would be fruitless.
For more information about TinyP2P, see http://www.freedom-to-tinker.com/tinyp2p.html.
Tinyswarm: P2P Swarming in
Inspired by Ed
Felten’s tinyp2p, I decided to write a slightly more
readable P2P program for swarming. From the header:
This will swarm a file using a small, known network of peers. No
attempt at peer discovery is made. Inspired by tinyp2p, but 10x
lo
It’s not a bug in xmlrpclib; there’s a problem with the “c” function:
def c(n): return ((lambda f: (f.read(), f.close()))( file(n) ))[0]
When I run this, the value of n is an empty list. Passing an empty list to the file constructor raises the Unicode coercion error.
I’m getting the same “coercing to Unicode” errors that Oyster is. I’m testing this under OSX 1.3.7 against Python 2.3. I suspect there’s a bug somewhere in xmlrpclib.py with this version of Python. If I find the problem, I’ll post it here.
Thanks for writing this, Dr. Felten. This is fun.
The new record is apparently 6 lines of Ruby by Florian Gross – see his posting in comp.lang.ruby. It uses a library to do a lot of the protocol work, but so does TinyP2P.
P2P Portable??
P2P Portable??
On the right to block issue. That is sticky, and it will only continue to get stickier. We need to right now start setting up a wireless, or some other hard to interfere, adhoc network, so that we can communicate unregulated.
As for the p2p code, anyone got an example for ruby or php?
P2P in 15 Lines of Python
P2P in 15 Lines of Python
Is there a non-obfuscated (obviously longer) version of this that we can study to see how it works? I realize it’s simple but I’m just too lazy to trace all the aliasing of actual module members.
I run the server
python tinyp2p.py mypwd server 192.168.0.1 56789
then the client
python tinyp2p.py mypwd client http://192.168.0.1:56789 (w)*.py
But I get the following errors, how to fix it? thanx
Traceback (most recent call last):
File “tinyp2p.py”, line 32, in ?
for url in pxy(ar[3]).f(pw(ar[3]), 0, []):
File “G:Pythonlibxmlrpclib.py”, line 821, in __call__
return self.__send(self.__name, args)
File “G:Pythonlibxmlrpclib.py”, line 975, in __request
verbose=self.__verbose
File “G:Pythonlibxmlrpclib.py”, line 853, in request
return self.parse_response(h.getfile())
File “G:Pythonlibxmlrpclib.py”, line 896, in parse_response
return u.close()
File “G:Pythonlibxmlrpclib.py”, line 571, in close
raise apply(Fault, (), self._stack[0])
xmlrpclib.Fault: <Fault 1: ‘exceptions.TypeError:coercing to Unicode: need string or buffer, list found’>
World’s Smallest P2P Code.
Alex Halderman and Ed Felten have done it again. They have their fingers in lots of cool pies…. They’ve made the code available for download, or cut and paste to iron it onto your favorite old T-Shirt. Tasty. Enjoy: #…
http://www.cnn.com/2004/TECH/biztech/12/14/tech.copyright.reut/index.html
A bit off topic, but this guy is crrrrrrrrrazy. Look, copyrights are good. They protect the creator of the material, without impeding the rights of others to recreate similar material (say, for example, a way to route traffic on the internet). I’ve come out and said before that I think software patents are bad. I still do, but I understand why they might be necessary in some cases (in others however, I think interoperability after X number of years (less than 20) should trump the patents). Gah. I’m too tired to be coherent.
I think Brice brings up an excellent point, but I think there is a more fundamental issue: we need the ability to send *information* from one person to another, not just exchange information with central content providers. As long as we’re able to exchange photos or movie clips with friends via email, we will still be able to use filesharing programs.
The danger is still there, though. If they eliminate our “right to route”, making it impossible for two clients to communicate directly, our last frontier of communication freedom seems to be email. Mailboxes are currently limited to 10 MB, but currently I think most email systems would allow someone to move large quantities of data as long as one client was actively receiving (and deleting new messages) at the same time the other was actively sending.
Even this could go away. We could be limited to only 10 MB of email per day, if email tunneling becomes popular and needs to be limited.
What can we do to ensure our future right and ability to exchange information? Does this future right-and-ability also affect multiplayer gaming? Video chat? Photo sharing with Grandma?
–Michael Spencer
Unfortunately, I’m not a Python hacker…
But, whenever I run the code I get the following error:
Traceback (most recent call last):
File “tinyp2p.py”, line 14, in ?
for url in pxy(ar[3]).f(pw(ar[3]),0,[]):
TypeError: iteration over non-sequence
attempts to ban their creation would be fruitless.
I am less worried about banning apps than I am about banning the right to route. Most of use with broadband have to send out packets through networks that are controlled by a small number of companies. It would be possible for the network to simply deny me the right to send packets to another “non-blessed” Ip. More here.
Very elegant. I especially like the use of lambdas to work around Python’s whitespace requirements. =) It was a good read.
As a diehard Perl hacker, I couldn’t resist the implied challenge. See my 9-line effort: MoleSter
Tiny P2P
Professor Felten teaches by example, writing a filesharing program in 15 lines of code: I wrote TinyP2P to illustrate the difficulty of regulating peer-to-peer applications. Peer-to-peer apps can be very simple, and any moderately skilled programmer ca…