switch to room list switch to menu My folders
Go to page: First ... 15 16 17 18 [19] 20 21 22 23 ... Last
[#] Mon Apr 19 2010 14:56:40 EDT from Spell Binder @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

One of my college networking textbooks classified transport-layer protocols two ways:

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.
Protocol Binder

[#] Mon Apr 19 2010 15:19:21 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

http responses are large, and will almost always come back as a more than one packet response.
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.

[#] Wed Apr 21 2010 15:35:41 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

UDP is good for things like streaming multimedia, where if a packet is dropped or garbled, its contents would be completely irrelevant by the time you tried to retransmit it.

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.

[#] Wed Apr 21 2010 17:58:35 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

like the  the VPN protocol is...

[#] Thu Apr 22 2010 07:57:59 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Right ... tunnels typically run over GRE (IP protocol 47). Ironically, the existence of NAT and misbehaving firewalls is the reason why many VPN systems now run over an SSL connection on TCP port 443, though. Firewalls can't tell the difference between that and an ordinary HTTPS transaction, so they let it through. It's quite common now.

[#] Thu Apr 22 2010 10:54:42 EDT from ax25 @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Thu Apr 22 2010 13:23:05 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Oh wow, that is super cool awesome. They built a full VPN out of it.

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.

[#] Thu Apr 22 2010 14:33:38 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Just got my n2n set up, and it's really easy and it works. Ford you're going to love this.

[#] Thu Apr 22 2010 14:39:48 EDT from ax25 @ Uncensored

Subject: n2n again.

[Reply] [ReplyQuoted] [Headers] [Print]

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:


[#] Thu Apr 22 2010 17:19:10 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Yeah, I'm probably going to be playing with this really soon.

[#] Thu Apr 22 2010 19:55:52 EDT from Ford II @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Sat Apr 24 2010 21:22:32 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I've just installed n2n as an always-on service on my main server at home, my desktop at work, and both of my laptops. It's going to be really nice not having to SSH through a bunch of different machines to get stuff done.
Not to mention, if either of the laptops go missing I can do ... things ... to them :)

[#] Mon Apr 26 2010 12:56:22 EDT from ax25 @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

n2n can both lower and increase productivity (double edged that way)...

[#] Mon Apr 26 2010 12:58:59 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

So far, I haven't been able to get it to work. But, I haven't tried very hard.

[#] Mon Apr 26 2010 13:01:22 EDT from ax25 @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Might need to open the port you are using for the supernode on the supernode end of things....

[#] Mon Apr 26 2010 15:08:52 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

I used someone else's open supernode, for testing purposes.

[#] Wed Apr 28 2010 09:24:47 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.

[#] Thu Apr 29 2010 12:56:54 EDT from dothebart @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

hm, day of the network outages...

dsl modem blocked ad home...

cable jumped out of

back online :]

[#] Thu May 06 2010 15:21:35 EDT from fleeb @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

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.

Any ideas?

[#] Thu May 06 2010 16:26:02 EDT from IGnatius T Foobar @ Uncensored

[Reply] [ReplyQuoted] [Headers] [Print]

Well, we were just talking about n2n, this sounds like a good application for it :)

Go to page: First ... 15 16 17 18 [19] 20 21 22 23 ... Last