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."
Haha, so much for their "please avoid submitting it to any high-traffic web sites, it is not yet ready for primetime" policy. Good work, anonymous submitter.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
But I don't plan on running limewire anytime soon.
I used to bulls-eye womp-rats in my pants
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.
p2pnet.net News:- Freenet author Ian Clarke is developing Dijjer, a new open source p2p content distribution tool, and he's looking for people to test drive it before it goes online in beta.
"Dijjer is a peer-to-peer HTTP cache, designed to allow the distribution of large files from Web servers while virtually eliminating the bandwidth cost to the file's publisher," he told p2pnet.
"Dijjer is designed to be simple, elegant, and to cleanly integrate with existing applications where possible. Dijjer uses "UDP hole punching" to allow it to operate from behind firewalls without any need for manual reconfiguration.
"Dijjer's distributed and scalable content distribution algorithm is inspired by Freenet."
Below is a brief Q&A.
p2pnet: When did you start working on this?
Clarke: Several months ago. It's hard to pinpoint a specific time because it's a combination of a variety of ideas that have been at the back of my mind for quite some time.
p2pnet: What prompted you?
Clarke: Dissatisfaction with apps like BitTorrent, and a desire to demonstrate that the ideas behind Freenet could be applied to solve other problems.
p2pnet: When do you expect (hope) it'll be completed?
Clarke: Well, I'm sure that development will continue for quite some time, but I hope to release a beta version in four to eight weeks that will be suitable for large-scale adoption.
p2pnet: Who do you see as the principle users?
Clarke: Anyone who needs to distribute large files to large numbers of people but who can't afford to pay for the bandwidth that this would normally require.
The download site says features include:
"No Firewall configuration
With many P2P applications you must reconfigure your firewall to get the most out of them. Not so with Dijjer, we use state-of-the-art "NAT2NAT" techniques to get the most out of your internet connection without any reconfiguration.
"Sequential downloads
If you tried to download a video through Dijjer you may have noticed that you could start watching the video before the download completed. This is because Dijjer behaves like a web server, pieces of a file are download in-order and fed to your web browser when they arrive, allowing your browser to start displaying content before it has completely downloaded.
"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!
"Cross platform and native compilable
Dijjer is implemented in Java, meaning that it will run on Windows, Linux, and Macs. Those who don't wish to install the Java Runtime Environment (JRE) will be pleased to note that Dijjer can be compiled with the GNU Compiler for Java (JCJ) to native code thus eliminating the need for a JRE. Native compiled versions of Dijjer will be available from this site in due course.
"Free as in Speech
Dijjer will be released under the GNU Public License.
"No cumbersome clients
Dijjer downloads through your web browser or preffered HTTP download application. You don't need to learn to use yet another P2P client user interface.
"Advanced scalable distributed caching algorithm
Dijjer uses a highly scalable distributed caching algorithm inspired by Freenet. This will allow it to deliver faster download speeds while placing less burden on the web server, and will be better able to handle sudden increases in demand for content."
"Now all I need are some people to help me test it,"says Clarke.
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
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 |
I am going to have to think about it before I install something that automatically reconfigures my firewall. NO!!
And what is this "udp hole punching"??
Rosco: "If brains were gunpowder, Enos couldn't blow his nose."
Or rather it CAN be faster depending on how you desing your protocol.
It'll still take some form of end-to-end acknowledgement scheme, but since it is pushed up to the application, there is less overhead overall.
Of course if EVERY app did this, it would really gum up the Internet.
I don't know the meaning of the word 'don't' - J
For those of us who can't read the code: how does this new feature work? How is it able to completely function behind a firewall?
I have bittorrent behind my firewall. Rather than statically allowing ports, I set up a "torrent" user, and told the firewall to let it listen for connections. This also has two beneficial side effects. First, if there's an arbitrary code vulnerability, an attacker can be somewhat contained. Second, bittorrent doesn't always use the common range of ports, so prioritizing by port is problematic. Having a seperate user lets me throttle the bittorrent connections so that interactive traffic has priority.
While I imagine this is possible with Linux, I have no specific knowledge of how to do it. I did it with PF on OpenBSD.
I rarely criticize things I don't care about.
you can pass any traffic you care to.
You may have to wait a LONG time if the port is throttled (hint to admins).
Now I'm the grandest Tiger in the Jungle!
This looks like an interesting hybrid of Coral and BitTorrent. Coral is nice in that you don't need to install any client-side software to take advantage of it. This one it appears you do need to install a client-side proxy, which is a little scary.
This system seems to utilize a client that takes on roles of both the BitTorrent tracker and the Coral caching nodes. I wonder how the client caches cooordinate? Any centralized server involved here?
Another firewall-busting HTTP serving system is YouServ (coral link), though geared more at sharing personal content instead of content requiring "super distribution".
Dijjer looks pretty cool, too bad all peer to peer protocols of any sort are banned at my university under pain of being blacklisted...
Pereant, inquit, qui ante nos nostra dixerunt.
"Confound those who have said our remarks before us."
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.
Wrong.
Besides the official site stating categorically no adware, spyware, or bundled software, have an actual read of the page you linked to. It's written by a desperately technologically impaired writer who probably just got these from another source.
Comment removed based on user account deletion
Why has it not been available before? I have been waiting for ages for p2p that works behind NAT. (I have to share my IP with 2 other guys that use the same P2P software)
Smoothwall GPL 2.0 final
POS PC = free from side of road
Smoothwall GPL = free
Problem solved..
If someone out there that is willing to put the time in to implementing a reliable UDP I'd be willing to share my notes and research on how to implement my ECIP error correction over IP as well as my SPAC Protocols. (Selective Packet Acknoledgement) algorythems. They can work together for a really cool solution.
The original code was lost when my former company went bust, it's was mess anyhow.
But the algorythems can be reimplemented.
ECIP
John L. Sokol
PS: Method of passing bi-directional data between two firewalls.
I wonder if anyone that's doing this read my paper on this?
I am always doing that which I can not do, in order that I may learn how to do it. - Pablo Picasso
"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.
I think of P2P much like having a wireless LAN in your house...that it's essentially inviting people into your systems that you otherwise wouldn't let in your house.
As a user, I can see that P2P could carry some bennies, but as an IT person, it makes little sense to secure your network, just to have someone using P2P letting outsiders in or bringing potentially tainted info in from the outside unattended.
How do we acheive a balance here?
This is cool !!
:)
Any idea how proxy servers find one another ? yes, I did RTFA
I would imagine some sort of overlay networks with ultrapeers.
I had wanted to do something like this using JXTA last year but alas, it has become yet another dead project on sf.
p2pbridge.sf.net
I am happy something similar has materialized.
Python script to convert photos into "artsy" portraits: http://p2pbridge.sf.net/pyPortrait/
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".
Most firewalls in home use are NAT firewall routers or software firewalls. Software firewalls are easy to configure to allow particular applications whatever network access they want, so let's assume we're talking about the former.
The NAT firewall wants to allow outbound traffic and deny any incoming traffic. But obviously all traffic requires packets to move in both directions, so it accomplishes this goal by allowing incoming hosts to initiate TCP connections to any external hosts they want, and then it maintains state about each connection, so that when response packets arrive, they can be routed to the right host inside the firewall. That's why we call the NAT a "stateful firewall."
I honestly don't remember and am too lazy to look it up; I'd guess NATs just note the source and destination ports in the TCP SYN and then associate return packets by using the source port. Maybe it uses some other tricks instead. But I digress.
So already you have problems with this scenario; what about FTP? This is a bummer because FTP (which predates most firewall designs by a bit) wants to have the destination open connections back to the source, on ports the source specifies. No reason to comment on that; they modified the protocol so that it wasn't necessary anymore (PASV mode) but also we note that many firewalls (including Linux I think) can actively watch the FTP control stream and thus anticipate and handle the new data streams properly. But now I digress even more.
The smart folks will by now be asking, "what about UDP?" And that's the question, isn't it. How do you think a stateful firewall like this has to handle UDP connections?
Remember, UDP has no built in "SYN/SYNACK/etc" semantics. There's no standard way to know what's going on when you see a particular UDP packet. It could be initiating some kind of connection, or closing it down, or carrying data; the bits inside the UDP packet are opaque to a firewall, because their meaning is up to whatever random software is using them.
I'm just guessing here, but it sounds like the standard NAT solution is to block all incoming UDP traffic, but whenever a firewalled host sends a UDP packet, then a "hole" is "punched" so that any UDP packets received from the destination host will be routed back inside to the firewalled source host. That would allow all your games and streaming media to work... And it makes a quick way to have two NAT firewalled hosts speak directly, as long as they both can coordinate their activities (which they can, with the help of a third peer, some anonymous P2P node).
Actually using UDP is a pretty good idea to begin with, because you can really optimize your wire protocol and gain a lot of speed (both better throughput and reduced latency). Also it will scale better and probably be easier on the internet (because UDP packets are often dropped by various routers in times of stress)... Perhaps we really should have been using UDP for P2P all along. But of course TCP is so much easier at the outset...
Tired of Political Trolls? Opt Out!
who cares about the health of the netowrk! udp time everyone!
The war with islam is a war on the beast
The war on terror is a war for peace
I just downloaded the .jar file and was alerted that a trojan had been installed. I'm not sure if anyone else had run into this but i'd download with caution
Acquisition is breaking the GPL. Dave Watanabe does not release his modifications to the limewire core until two versions later.
The GPL states clearly - if you release a binary, you have to make the code available. He does that with a month or so delay - which is still a GPL violation.
So how does the connection get initiated? Both clients behind NAT's need to get each other their NAT's IP addresses for this to work.
This is pretty easy if you have a 3rd party server to bounce initial requests off of (both clients subscribing and listening for initiation requests), but then it's not really peer-to-peer, is it?
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
UDP Hole Punching won't work on an actual "firewall". Instead it's meant to get through these home-type NAT boxes that people are calling firewalls but which really are not.
The problem with getting stuff across a NAT gateway is that communication must go through the NAT, and the NAT is generally configured to block incoming traffic unless it's expecting it.
See, NAT works by pretending to be you. When you go get a web page, you send a packet to a webserver. The NAT box, being your gateway, gets this packet, then sends out a reformatted packet of it's own to that webserver. It opens a return port to get the data from that webserver and this gets forwarded along to the receiving system. Basically you're changing the addresses used in both ways, so as to munge the thing between the private and public IP address space.
UDP works in a similar way, it's just modifying addresses going through the gateway. However, with UDP, usually the port number doesn't change. Meaning that when I send a packet out, I don't get to specify what port the responding host sends a return packet back to. I'm expected to know that it'll be coming back on the same port. So NAT deals with UDP pretty simply. The outgoing port and incoming port are the same. This is open to possible abuse, so most NAT boxes only forward packets from the original host back to the private network.
That's potentially confusing, so I'll use an example:
Computer A is behind a NAT. He sends a UDP packet to computer B on the public internet, on port 30000. The NAT munges the outgoing address and forwards it to computer B. Computer B sends back a UDP packet on port 30000. The NAT verifies that he is only allowing B to respond on that port, and sends the packet back to computer A. If computer C were to send something to the NAT on port 30000, it would be discarded by the NAT (not all NAT's do this, some allow anything in for a short time instead).
In the case where only one system is behind a NAT, this is easy to solve. The computer behind the NAT must initiate the connection. That's all there is to it. Computer A initiating the connection makes it possible for the NAT to send stuff back to computer A, and so all is good.
In the case where both computers A and B are behind their own NAT, suddenly they have no way to talk to each other. Anything A sends to B gets dropped by B's NAT, and anything B sends to A gets dropped by A's NAT. The only fix for this has been port forwarding, which manually punches a hole in one or both NAT devices.
UDP Hole Punching exploits the UDP behavior of NAT devices to allow A and B to communicate directly without any port forwarding being needed. It works like this:
Computer A sends a UDP packet to computer B on port 30000. This act opens the hole in the NAT for B to talk to A on port 30000. At the same time, A sends a packet to Server S on the P2P network. This packet basically asks computer B to send something to computer A on port 30000. Server S routes the packet to computer B over the already setup P2P network. Computer B then sends something to computer A on the given port, and they can now talk directly and setup other ports if they likee by this single channel of communication that they have gotten open.
And that's all it is, really. Just a way of using an intermediary that can talk to both A and B (via the already established P2P routing) to allow them to talk directly. Nothing particularly tricky.
Why UDP? Because UDP doesn't get the port changed by the NAT. TCP connections over a NAT usually get ports munged by the NAT without informing the computer behind the NAT. That's part of the "transparency" portion of NAT. The less tricky behavior of UDP on a NAT device makes this possible.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
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
Lots of ISPs implement egress filtering these days to reduce forged IP source addresses.
The problem it's solving is actually with NAT, although it'll also apply to some kinda-weak firewalls.
- Give a man a fire and he's warm for a day, but set him on fire and he's warm for the rest of his life.
Though this program is geared more for firewalls, does anyone have a similar item for Squid Proxies? It seems the bastards at my world even disabled the TCP tunneling port on the Squid server, so I am looking for other means of outside TCP connectivity.
Dijjer respects the various no-cache HTTP headers, a robots.txt file is intended for search engines, not caches.
Just make your web server reject or redirect links that do not report Dijjer as their HTTP client. Easy.
I have been really wondering when someone was going to do this for P2P apps. Compared to how much other software actually uses the same techniques, it's long overdue. There seems to be some misconceptions on how it works though in the comments here, so I'll try to do a simple explination:
UDP is stateless. There is no connection setup like there is with TCP so there's really no way for a firewall or gateway to statefully track where to send UDP packets, so the typical implementation for NAT'ing UDP is something of a 'best guess' scenario, redirecting certain packets based on port numbers and IP's. These new applications take advantage of this synchronous behavior of NAT devices to permit direct connection between client computers where both are behind NAT firewalls.
NAT of UDP is generally implemented like this: If you begin sending UDP from source port 2000 on your computer to a remote host on port 5000, then the router doing NAT will automatically open up a 'hole' that allows any UDP packet from the remote host from source port 5000 to destination port 2000 on your machine to pass through to you. This is sort of how it works with TCP too; however the firewall only opens up the 'holes' when connections are first set up and only allows packets with correct sequence numbers to pass back through.
Essentially how it works is that two clients decide to "connect" and agree on port numbers, etc through some third host that both can reach via tcp. They then begin broadcasting UDP data to each other. Once a packet goes out from both hosts, the two 'holes' in the firewall will open up. Probably at least one packet will not actually arrive at its indended destination; however, the software can implement its own robust transfer protocol over UDP.
Games have been doing this forever. QuakeWorld (the Quake 1 client tailored to internet play) was one of the first to implement it. Most implentations of SIP support this type of connection.
UDP [Unreliable Datagram Protocol]
Good description. But it is User Datagram Protocol
A house divided against itself cannot stand.
Related to this, check out the Visual P2P/Swarming Simulation.
It allows you to visualize firewalled transfers.
If I understand this correctly, this could be implemented to solve the slashdot effect, as long as the majority of slashdotters ran this program somehow? what if it was just a Firefox extension?
Nice signature -- Sierpinski Triangle -- very cool -- Steve
Just tried it out, so this is speaking from actual experience. Digger doesn't limit itself to sharing files you have already downloaded - it will *actively* download files other people are requesting, so that it can share them.
This is simmilar to freenet, and indeed will maximize everyone's bandwidth. But it has grave issues when not combined with Freenet's huge anonymimity factors like encryption and hiding IPs , and will open you up to all sorts of legal problems.
I don't want the FBI knocking down my door because my Dijjer client has been downloading kiddie porn for someone else without my knowledge. Sure, I *may* be able to argue in court that it was not me, and hey, I may even be able to prove it. But is that potential trouble worth my saving on some bandwidth? I think not.
Saw this a couple of days ago. Pretty vague description,
but it does promise exactly what you are looking for. 2c.
3.243F6A8885A308D313
Comment removed based on user account deletion
Sure, here is some proof. I downloaded the dijjer.jar of the download page. I ran it, and clicked the test link on the main Dijjer page - the link for the Linux kernel. I clicked no other link and did nothing else except look at the status page.
u tio2001.mpeg chunk 3 at ttl 9u tio2001.mpeg to retrieve chunk 3u tio2001.mpeg chunk 1 at ttl 9u tio2001.mpeg to retrieve chunk 1
Meanwhile, check out some of the output from the server, printed right to STDOUT. Remember - I did not download this file, or make a request for it, and it certianly does not exist on my machine:
8950 -1 -> lysanderspooner.xs4all.nl:9114 : acknowledgeRequest {uid=-363110451
Dispatcher: Retrieving http://www.archive.org/download/Evolutio2001/Evol
LOOP: Find peer for requestData
Dispatcher: Connecting to http://www.archive.org/download/Evolutio2001/Evol
9023 9114 lysanderspooner.xs4all.nl:9114 : acknowledgeRequest {uid=-2112834057
Dispatcher: Retrieving http://www.archive.org/download/Evolutio2001/Evol
LOOP: Find peer for requestData
Dispatcher: Connecting to http://www.archive.org/download/Evolutio2001/Evol
Retrieved block 50
Dijjer does not create any more liability for its users than a HTTP cache creates for an ISP, and note that virtually all ISPs run HTTP caches, so far as I know, without encountering legal problems.
do you pronounce it?
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.
Ian Clarke? Shouldn't he be busy with getting Freenet to a usable state?
quidquid latine dictum sit altum videtur.
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.
Comment removed based on user account deletion
Ever heard of ICMP or more specifically - DestUnreachable/PortUnreachable code ?
It is essentially a guaranteed system-level NACK, which comes handy exactly in the situation you describe. Every decent NACK-based protocol implementation has ICMP handler (see SOL_IP, IP_RECVERR in setsockopt).
3.243F6A8885A308D313
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)
Shareaza
The power of accurate observation is commonly called cynicism by those who have not got it. -- G.B. Shaw
"New P2P program beta testing.
sloncek @ 23-11-2004 12:47
Like before, we are looking for beta testers, to test a new P2P program.
If you would like to help us, please click here and enter your forum nickname in the form on the website.
In order to participate in the beta testing, you need to be a member of our forum . If you are not yet a member, just follow this link and register there. You will need to have at least three (3) posts on the forum in order to be able to participate in the beta testing.
Please only register for the beta testing if you really plan on helping test the program. Meaning you will download and upload with/in the program.
The program is for Windows only!
Hurry because there are only 5000 places available!"
hmmmmm...I wonder what sloncek is up to...
The power of accurate observation is commonly called cynicism by those who have not got it. -- G.B. Shaw
P.S. how well does that guaranteed system-level NACK work when someone is using a P2P protocol designed to sneak through firewalls? (Especially if it's a magic "stealth" firewall that eats ICMP packets coming back saying the port is unreachable?)
One line blog. I hear that they're called Twitters now.
'Stealth mode' firewall normally eats ingress pings and egress 'ttl expired'. And some other rarely used ICMP types.
Never should it block ingress ICMP/DestUnreachable for Related egress TCP or UDP traffic, because this will break tons of various applications.
If eDonkey and BitTorrent ignore UDP socket errors, it just speaks that much of their developers, not the fact that NACK-based protocols are bad.
One way or another Reliable UDP (or any other custom quasi-L2 protocol for that matter) is rather advanced subject. If someone decides to tackle it, I just hope they are over-skilled and under-confident and not the other way around.
3.243F6A8885A308D313
like right that's yeah happen gonna.
Join the Slashcott! Feb 10 thru Feb 17!
I can't speak for the designers of the P2P protocols. I haven't looked at their code to see what happens, and the documentation tends to be sketchy. I don't know why most tend to keep trying for days, only that they do. I only hope that the UDP P2Ps are better implemented--especially by the more enthusiastic implementors who frequently tweek without understanding.
One line blog. I hear that they're called Twitters now.
You can't get both TCP and UDP into the same packet without encapsulation.
Almost all of the properties that UDP shares with IP are a result of it sitting on top of IP. Kinda like the way that a minimal subclass shares properties with it's parent class.
Both TCP and UDP sit on top of IP, as does ICMP and a number of other protocls -- in fact both TCP and UDP sit on top of either IP4 or IP6. You don't have to change the tcp/udp code when you switch to IP4 -- just the IP code (that's the whole purpose of the layering process).
Free Software: Like love, it grows best when given away.
Comment removed based on user account deletion
Could this possibly be leveraged to help alleviate some of the problems associated with RSS taking up so much bandwidth? Obviously yes, at least to some extent. But what would it take to become feasible and widespread?
Hi guys,
f
Our group actually has a paper in this years HPDC conference, that shows a method to do hole puncing with TCP. We call it TCP splicing. This way, you don't have to implement a reliability protocol on top of UDP.
You can find it at www.cs.vu.nl/ibis -> publications...
Alexandre Denis, Olivier Aumage, Rutger Hofman, Kees Verstoep, Thilo Kielmann, Henri E. Bal:
Wide-Area Communication for Grids: An Integrated Solution to Connectivity, Performance and Security Problems,
Accepted for publication, HPDC-13, June 2004, Honolulu, USA.
Here is a direct link:
http://www.cs.vu.nl/ibis/papers/hpdc2004-denis.pd
Cheers,
Rob
It is not just a cache. It is like Freenet.
A cache would take things you have downloaded and share them with others. THis is what all other P2P does. This is good.
Dijjer shares things you *havent* downloaded - it downloads things you never requested using yoru spare bandwidth and shares them with others. As in, it downlods and shares things I never asked it to download.
This is why it opens up logal problems. My Dijjer client could be downloading kiddie porn even though I never requested it, just because someone else on the Dijjer network did and I was connected to him at the time.
It would be more like a super-efficient and easy to use Bittorrent that works through any firewall.
IMO this feature has to go - the thing is still immensly usefull without it.
As a Dijjer user you are in exactly the position of an ISP running a HTTP cache, where your customers are the Dijjer user base.
Read the link to the DMCA I reference, I think you will find that the DMCA perfectly describes what Dijjer does.
The DMCA exemtoins to ISPs have absolutely nothing to dow ith child pornography. As a parent poster said, the law does not care how or why you have the child porn in your posession. Even if you got it by accident, or via a service you provide to other parties, you can still be prosecuted and convicted.
An ISP whose HTTP cache contained child porn *could* be prosecuted and convicted as well. But it would be quite obvious to the Feds that they were an unknowning intermediary, so the likelihood of that would be small.
But how obvious would it be to the Feds that the HTTP download from X porn site was being made by someone else but not you? Good luck with that - I will stay away thanks.
But the problem here is that this RFC is being preached to be implemented on NATting devices, like firewalls. So, I wouldn't imagine any "big" firewall vendor to implement another model for P2P :-)
And BTW, m$ have just implemented that for WinXP & Win2K machines!
"Evil thrives when good men do nothing"