1. Connection-oriented vs. connectionless.
2. Reliable vs. unreliable.
TCP is a connection-oriented, reliable protocol, whereas UDP is a connectionless unreliable protocol.
As IG alludes to, UDP, because of its low overhead (both in header size and complexity) makes an excellent foundation for building protocols that fall into the other categories.
I've always thought that reliable connectionless protocols are excellent for applications where small packets of data need to be delivered in tact.
In fact, I sometimes wonder why HTTP runs on top of TCP.
Most HTTP transactions are small GET requests from the client to the server followed by relatively large replies from the server back to the client. Why couldn't the GET be sent using a reliable connectionless protocol and the reply sent back over a TCP connection?
The first big answer that comes to mind is that if you're going to need a reliable connection to get the reply, why not just open it up for the request as well and get the connection set-up out of the way. I'm not sure I buy that, though. Especially with some web applications playing games where they'll send part of the page, and then make the client wait until new data arrives, it almost seems like a waste to have to setup a connection.
The other answer I can think of is NAT. NAT makes it difficult for inbound connections to be setup. Either your software has to be NAT-aware, or the NAT device needs to be insecure or really intelligent.
If you were to use UDP, very likely a packet would get lost or misordered here and there, and the browser would have to basically reinvent TCP to ensure it got the response back correctly.
UDP is good for stateless question answer sessions, and in the case of large responses, state is required in the sense that you need all the packets and you need them in order.
http HEAD could probably be implemented in UDP without too much effort, but who needs that.
Now if you *really* want to fly under the radar, you can just write your own layer 4 protocol directly on top of IP. That probably does require a privileged level of execution within the operating system though.
like the the VPN protocol is...
The hole punching has been done already:
You need another accessable address outside the 2 "edge" nodes, but it seems to be working well for me at least. The code is even documented a bit and still a small code base.
What would be cool would be if they offered just the transport layer as a separate library that could be used to add P2P technology into existing applications.
Subject: n2n again.
Yes N2N is super simple. I especially like the "dangerous" enable packet forwarding setting :-)
For those that are MS inclined, there is a GUI installer:
Yeah, I'm probably going to be playing with this really soon.
Just got my n2n set up, and it's really easy and it works. Ford you're
going to love this.
You mean something else I'm going to try and rewrite badly?
I'll take a look tomorrow.
Not to mention, if either of the laptops go missing I can do ... things ... to them :)
So far, I haven't been able to get it to work. But, I haven't tried very hard.
I used someone else's open supernode, for testing purposes.
Finally figured out why I couldn't ssh to my linux system at home from outside the router.
I was fiddling with the wrong router settings. I kind of feel stupid as a consequence.
hm, day of the network outages...
dsl modem blocked ad home...
cable jumped out of outgesourced.org...
back online :]
I might have a fun problem for you folks.
We have a server at a remote location. The server is behind a router connected to a DSL line. I don't know much more than that, except that the DSL line is pretty close to the maximum distance from the CO possible before you can't get a DSL connection (not sure if this is relevant, but there you go).
I can use our client to connect to this box and stream a/v content without issue. Everything works just fine.
Person A can also connect to the box without any issues.
Person B can establish a connection, but does not get a/v content. It's as if those packets are blocked. Yet, B can connect to another server without issue (so we know the client software is not an issue... this is a network-related problem).
We have other examples of persons A and B (able to connect, or not able to connect), but we do not see a clear pattern as to what makes these guys different from each other.
Of course, I haven't been able to run as deep a set of diagnostics as I might like on all those machines.
Now, here's the bit that might (maybe) help you help me figure this problem out... I cannot establish a desktop connection to the machine. If I use one tool, the connection can't get established at all (LogMeIn). If I use another tool, the connection is established, but I cannot see a desktop... although it will let me use one of its built-in tools to browse files on the server.