P2P Through Firewalls 220
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."
I don't know about you (Score:4, Interesting)
Been waiting for this! (Score:2, Interesting)
Seems like somebody finally came up with the answer!
Freespirit
Limewire = java based. (Score:3, Interesting)
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.
Dijjer (Score:3, Interesting)
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.
VPN-mesh? (Score:5, Interesting)
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. =)
But... (Score:3, Interesting)
Or perhaps the problem is rather with NAT? In that case, I'm still hoping that someday someone will implement something like RFC 1701 [faqs.org] or somesuch instead of continuously reinventing the wheel.
what's the big problem? (Score:3, Interesting)
POS PC = free from side of road
Smoothwall GPL = free
Problem solved..
Re:Dijjer is self defeating (Score:1, Interesting)
Re:Reliable... udp... transfers? (Score:5, Interesting)
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.
Re:Been waiting for this! (Score:3, Interesting)
Essentially, UDP is a stateless system, so stateful firewalls don't have SYN packets to signal the start of a connection, so you can do the following
- Machine A sends a UDP packet from port X to machine B Port Y, and
- Machine A's firewall will create a connection for the outgoing address/port pair
- (Machine B's firewall will drop the packet because there is no connection associated with it)
- Machine B then sends a UDP packet from port Y to machine A Port X
- Machine B's firewall will create a connection based on the address/port pair.
- Machine A's firewall will accept (and route) the connection as belonging to a legitmate connection.
- All further connections between A and B based on this address/port pair should work until further notice
Note that this will not work on firewalls that use port randomizing on outgoing connections. More work has to be done to make that work. This also (obviously) requires a mediating connection where the two can agree on what addresses and ports to send from and to. (If a machine is inside of a NAT it may not realize what it's post-translated address is).As long as you don't have port randomizing, this should work on both NATed and non-NATed statefull firewalls.
*Any* URL? (Score:3, Interesting)
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.
Re:Problem with Dijjler (Score:3, Interesting)