P2P Through Firewalls

← Back to Stories (view on slashdot.org)

Posted by ryuzaki0 on Tuesday November 23, 2004 @06:34AM from the file-in-hand-worth-two-in-the-network dept.

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."

11 of 220 comments (clear)

Min score:

Reason:

Sort:

But... by remigo · 2004-11-23 06:37 · Score: 5, Insightful

But... I thought that peer-to-peer sharing was horribly immoral and only used for warez and porn!!

Seriously, though, this is the kind of thing that I desperately wish mainstream media/Congress paid more attention to. It's only the lawsuits and illegal uses that get covered because that's what sells ads.
Re:please dont by nocomment · 2004-11-23 06:38 · Score: 3, Insightful

hmmm. I don't care if it's ready for primetime or not. GTK-Gnutella works just fine with firewalls.

--
/* oops I accidentally made a comment, sorry */
/* http://allyourbasearebelongto.us */
Reliable... udp... transfers? by 192939495969798999 · 2004-11-23 06:41 · Score: 5, Insightful

It strikes me that one could set up a server to cache udp requests and serve them back out to the attached/requested clients reliably. 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.

--
stuff |
1. Re:Reliable... udp... transfers? by Spy+Hunter · 2004-11-23 07:27 · Score: 5, Insightful
  
  TCP errs on the side of caution. The failure mode of TCP on congested links is to stop. These new UDP transfer protocols have a "damn the network, just send my bits!" attitude that could be bad for the health of the Internet as a whole. The failure mode of a NACK protocol is to flood the pipe with data that never reaches its destination, while the NACK packets never reach back to the source. Widespread use of unproven UDP transfer protocols with bad congestion control could flood the entire Internet with uncontrolled traffic, making it impossible to establish a TCP connection because of high packet loss, and reducing throughput for all. All in the name of getting a few percent more speed on long links. These people should be working together through the IETF to publish RFCs on a real replacement for TCP, not writing their own vigilante protocols on top of UDP.
  
  --
  main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
2. Re:Reliable... udp... transfers? by AndroidCat · 2004-11-23 07:34 · Score: 3, Insightful
  
  Oh good! So when someone starts a moby transfer that's going to take forever, and crashes his machine trying to game with scores of spyware running at the same time, then I can be next in line to pick up his old DHCP dynamic IP address.
  I'm so looking forward to having my bandwidth eaten by a system that wants a precise STFU packet to stop spewing at me.
  
  --
  One line blog. I hear that they're called Twitters now.
Dijjer is self defeating by AIX-Hood · 2004-11-23 06:58 · Score: 4, Insightful

"No "Tracker" necessary, works with virtually any URL 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! As the that guy who runs filerush, I'm always looking to move to whatever will keep the files free flowing with zero hassle. The problem is that this method just shot itself in the foot. So you're saying that I have to serve my 350 meg new game demo on my regular http server and Dijjer users will P2P it without my knowledge. That's great.. but what about the other million users who have no idea about Dijjer, and just hammered my download and therefore my site in extinction because I can't tell who's who? Now nobody gets the file.
Followed by virus-through-firewall applications by Animats · 2004-11-23 07:03 · Score: 2, Insightful

If P2P through firewalls is deployed, viruses through firewalls can't be far behind.
0wn corporate networks! Laugh at their ineffective firewalls. Use them to send spam all night! Resell them on Spamforum.biz. At last, the killer app for "grid computing".
Re:Limewire = java based. by AIX-Hood · 2004-11-23 07:09 · Score: 2, Insightful

He should be using Acquisition for OS X. It's the coolest Limewire app out there with full iTunes integration and never slows down your machine. He'll never look back.
Mod parent up. by apankrat · 2004-11-23 07:24 · Score: 2, Insightful

And mod me up while you're at it :)

Most of reliable UDP protocols do use unsolicited NACK'ing and solicited ACK'ing. This cuts down overhead on fat pipes to just one ACK per a transfer, which is as low as it gets.

This approach doesn't work well on lossy links or for interactive sessions though.

--
3.243F6A8885A308D313
Re:Reliable... (TCP/IP vs TCP/UDP) by Stephen+Samuel · 2004-11-23 09:52 · Score: 2, Insightful

UDP isn't similar to IP. It sits on top of IP, just like TCP does. The main difference between UDP and TCP is that TCP has reliability built in. The protocol will automatically re-order out of sequence packets, figure out which ones are missing and have them retransmitted before it delivers the data to the recipient.
With UDP, if you want reliable transmission, then you have to do all that work yourself. If you have a generally reliable link, then this can be very cheap. It's also very cheap if you only want to send a little bit of data (say, one line of text).
With TCP it takes at least three packets just to open the connection -- before you can even transmit data -- and then another three to close it. That gives you a minimum of 6 packets with no actual transmitted data.
With UDP, a very simple transaction can consist of
a -> B (( DATA ))
B -> a (( ACK: CRC was X) [[ optional ]]
As long as the checksum is good, A need do nothing. If the checksum was bad (or no ACK comes back) then A can retransmit). If you don't mind losing the data altogether, then even the ACK is unnecessary.
UDP can be fast and cheap, but to avoid beating the internet to death on bulk transfers it depends on the application being well-designed to prevent bad side effects.... That intelligence is built into TCP (but at a cost).
As long as you can handle losing the occasional packet and/or having packets arrive out of order and you don't threaten hog the entire bandwidth of your pipe, then UDP is fine.
If you don't want to worry about the above, and you're willing to put up with the overhead of TCP, then TCP is your best bet. This turns out to be the case for the majority of applications, which is why TCP seems to be way more common than UDP -- SO much so that many people don't even relize that you can have IP without TCP (( the 'TCP/IP' misnomer contributes to this)).

--
Free Software: Like love, it grows best when given away.
Generic Matchmaker? by bill_mcgonigle · 2004-11-23 10:55 · Score: 2, Insightful

But the point is that this matchmaker still has a very low load, and can exit once the connection is established, so that is not that bad compared to what would happen if he served as a proxy for all the data instead.

Is there a generic (P2P Protocol Agnostic) matchmakerd? Seems silly to have one for each network. If there were a standard, I could, for example, put a call through to my parents' video phone without having to know their IP address if we both subscribed to the same matchmaker or network of matchmakers. Without a generic standard the proverbial videophone firmware developer isn't going to be able to offer me a field for query service server.

--
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)