Problem: The main problem with peer to peer file sharing networks is that people are not sharing because they are afraid of being sued. Recently, 4 students in the US have been sued for $97 million dollars due to sharing files. If people stop sharing, networks will die. (Only once is the whole process is a real IP address used, and that is after the request, and the offer.)
Solution: We aim to make a P2P app that uses spoofed UDP packets for initial communication, and also for file transfer. This will ensure that the file sender stays unknown.
Download: Currently all work is continuing in CVS
If you want to check out a copy, do this:
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/udpp2p login (Hit enter)
cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/udpp2p co udpp2p
To compile, you will need libnet installed.
To run, use ./main
Warning - it's still currently being worked on, and it has lots of debugging statements.
To check the file transfer:
gcc -o recvfile recvfile.c ; gcc -o sendfile sendfile.c -lnet
All the ip addresses and ports are hardcoded in at the moment. We will write a config file, and reader, but until now, just grep for 192.168, change to suit you, and recompile.
Todo: To do list (CVS)
Some brief docs: Brief docs (CVS)
Method of operation:
Each client has a list of IP addresses of other people running this service. (How it gets these is irrelevant. Discovery packets, find-a-friend packets, lists on peoples websites, word of mouth, whatever).
When a client wants to search for a file, it sends a "type 1" packet to those
IP addresses with spoofed source addresses. (This is what we mean by
broadcast). It embeds a random number (the request ID ) in the request so
that it can detect replies to that request.
If a machine receives a type 1 (request) packet, it immediately increments the hop count field, and if that isn't over a preset amount, it forwards the traffic to the IP addresses in its list. Then, it checks if it has the file in the filename field.
If it has the file, it sends a type 2 (offer) packet to the hosts in its list, including the original random number, and a new random number ( the offer ID ).
If the original host receives a type 2 packet that contains the original request ID, it knows that this message is in reply to one if its requests. it can then (if it chooses) send a type 3 packet out (an accept packet) with the offer id, and include its real IP address, and a random port, which it has spawned a listener on, ready for the file. This is the only stage where a non-spoofed IP address gets used.
When the host with the file receives the type 3 accept packet, with the offer ID in it, it starts sending the file (with spoofed source addresses) to the IP address in the packet.
This all works at the moment.
There are a few large problems though.
1. Flow control, if you don't know the senders IP address. We propose the
sender slowly increases its speed, and if it receives a "slow down" broadcast
with the offer ID in it, it doesn't send so fast. Also, we will use sequenced
packets, so that the receiver can detect whether it has missed a packet, and
hence can send a "slow down" broadcast.
2. We wrote a simple sender and receiver program. The sender sends /etc/motd to the receiver. (IP addresses are hard coded in for now). If we use a different random source address for each packet, we see that the 2nd packet of the transfer always gets ignored by the receiver. If we choose a random address, and use the same one for the whole transfer, it seems to work OK. tcpdump on the sender and receiver show the 2nd packet is actually sent, and received, but for some reason doesn't get processed by the stack.
If you want to just check the code out, get libnet installed, change the IP addresses and compile it up, you'll see it (basically) working until it reaches the file transfer stage.
Another problem is the fact that decent ISPs filter traffic that doesn't appear to come from their IP ranges. We will solve this by using an adjustable randomiser - i.e. /8 all the way through to /30.
However, we are really keen to hear from anyone that has any insights into why this would work, why this wouldn't, or has any suggestions to make it work better.
Many thanks,
The UDPP2P team.
<projectname>at umtstrial.co.unitedkingdom