Slashdot Mirror
P2P Through Firewalls
An anonymous submitter writes "A few stream-through-firewall applications have been announced recently. p2pnet has an interview with Ian Clarke about his new 'Dijjer' program, which promises to reduce bandwidth requirements from HTTP servers by transparently distributing the load. Slyck.com has an article about LimeWire's new version that offers firewall-to-firewall transfers (code here). [Both Dijjer and LimeWire are GPL'd.] There's also been a lot of discussion on the p2p hackers list about reliable UDP transfers."
But I don't plan on running limewire anytime soon.
I used to bulls-eye womp-rats in my pants
It has been a long running discussion in my project lab at the university, how to make a p2p program (in our example, Skype) work between two networks using NAT-firewalls.
:-)
Seems like somebody finally came up with the answer!
Freespirit
My father, who's using a mac, loves limewire beacuse it melts perfectly in to his UI. But he can't do anything else while he has limewire running; except play solitare and shanghai.
Personnaly I think limewire sucks. Here's the reasons. 1. It's slow and processor hogging.
2. It dosen't melt into my fluxbox theme. (my fault)
3: It requires Java.
But for the ordinary user I think limewire is the best p2p software out there.
Fear kazaa though.
God,root what's the difference? I read slashdot, there for I errr... am stupid?
"Dijjer will work with almost any direct URL, the content publisher doesn't need to lift a finger - they may not even realise that people are using Dijjer to save their bandwidth costs!"
That is a good thing, but potentially a bad as well, for how some sites make money... I think a needed features is a robot.txt entry that blocks dijjer from caching the site.
I'll be the first to admit that I'm an idiot; but what about using VPN's to secure and mesh these P2P hubs together?
Each PC that wants to share data, acts as a hub with x-number of tunnels going out at one time. The content of each hub could be spidered and locally cached. (kind of like combining a router-cache with a Freenet hub)
It might be slower (like DC++) but you could setup groups of peers that get preferential bandwidth.
BUT you could always add a swarm-like functinality of BT.
a) secure from **AA (as long as you don't let them into your peer-group)
b) distributed load (no central server to take down)
c) because it is a VPN, you don't need to worry a firewall because YOU initiate the connection and keep it open. {I do know that you are fubar if the firewall admin blocks the ports, but wouldn't you be SOL anyway?}
d) well, I just think it sounds kida cool. =)
"The price good men pay for indifference to public affairs is to be ruled by evil men." ~Plato (427-347 BC)
And I thought firewalls were supposed to stop certain services...isn't "P2P Through Firewalls" defeating the purpose?
Or perhaps the problem is rather with NAT? In that case, I'm still hoping that someday someone will implement something like RFC 1701 or somesuch instead of continuously reinventing the wheel.
Please correct me if I got my facts wrong.
Smoothwall GPL 2.0 final
POS PC = free from side of road
Smoothwall GPL = free
Problem solved..
That's why Coral is client oblivious, so everybody downloads it using a Coralized link.
p2p traffic is large static files almost 100% of the time. A UDP protocol optimized for large files can be a good thing, better than TCP.
a) Instead of a relative small window like TCP, we can make the window as big as we want. This would let us cut down a LOT on ACKs (or pseudo-ACKS in the case of UDP). We can ACK a range, or a range with exceptions, or whatever. For a protocol specializing in bulk transfers, it can really cut down on overhead.
b) TCP guarantees that data arrives to the application in order. This is expensive when we don't care. A custom UDP protocol lets us pick up missing chunks at our leisure, we simply need to maintain a list of missing chunks as the transfer goes along so we can request them later.
c) Since UDP is connectionless, firewalls must create pseudo-connections for UDP. When a UDP packet is sent, the firewall will allow incoming UDP packets from that host/port to the originating port. This gives us a way of signaling to the firewall that we wish to accept UDP packets from that host on that port, even though the client on the other end will never recieve that packet due to their own firewall. Once they've both done it, they have a mutual "connection". This is a brilliant hack, whoever thought of it.
d) We can hide the sender of the data. If we request a file in some mutually accessible place, along with the host/port we're going expect packets from, anyone anywhere can start spewing packets at us with falsified sender information. It's nearly impossible to determine where they came from with UDP.
"However, one must wonder why not just use TCP, which is guaranteed to be reliable. IMHO, What you'd end up with using UDP is a LOT of "did you get it? yes/no"-type network traffic between peers."
TCP does that a lot too (a LOT), it's simply handled by the network stack rather than the application. TCP ACKs cause 1/15th or 1/20th as much upstream traffic as the downstream portion of the connection causes. That adds up when you have a {dsl,cable} modem that's 1/10th as fast with upstream traffic.
I rarely criticize things I don't care about.
This is a big one, Dijjer will work with almost any direct URL, the content publisher doesn't need to lift a finger - they may not even realise that people are using Dijjer to save their bandwidth costs!
So, am I to understand that when using dijjer you are broadcasting your web surfing habits all the time in the hopes that someone other than marketers and police are out there listening? Or is there some anonymizing Freenet magic going on here? Giving up my privacy to save someone else a dime doesn't sound like a good idea to me.