So let me see if I understand.

It's a breeze to get my firewall to accept incoming TCP packets from A or from B. But there are special routing permissions necessary to forward packets from A to B or from B to A, and it would be a nightmare to keep routing tables straight?

Speaking of firewalls, I have my FN UDP port forwarded both at my router and at my computer firewall. Most the time everything is fine, but once in a while I get a "You appear to be behind a NAT" warning. I dismiss the warning and I don't see anything for several hours or days. Is this normal?

On 01/21/2011 12:19 PM, Phillip Hutchings wrote:
On 22/01/2011, at 8:04 AM, Ray Jones wrote:

On 01/21/2011 11:59 AM, Phillip Hutchings wrote:
On 22/01/2011, at 7:55 AM, Dennis Nezic wrote:

On Fri, 21 Jan 2011 11:51:35 -0700, Ray Jones wrote:
If I understand correctly....

UDP has no such thing as flow control. So even though your machine
reads only X packets per second, the sending machine is still sending
and you're still receiving. If the packets build up too far your
machine will drop them, but you've already used the bandwidth to get
them there before they were dropped!
I agree it's a terrible waste -- but, I say, tough luck. Surely the
senders will throttle back when they start seeing some of their packets
not being acknowledged. (Like I said, we should avoid this situation as
much as possible, but ultimately the user has to be in control. The
network, selfish as this might sound, comes second!)
NO! We're using UDP - UDP packets have no acknowledgment. TCP would behave like 
you describe, but UDP senders have no way of knowing that there's a problem.
Which brings this non-techies to the obvious (to me) question: So why are we 
using UDP instead of TCP?
Because UDP is easier to get through firewalls. TCP has state, so the firewall 
has to know you want to receive packets on a port, and it can identify the 
difference between an outgoing an incoming connection. With a network setup 
like this

A |firewall|<---->   C<----->  |firewall| B

if A wants to talk to B, B needs to configure their firewall to allow it. They 
can both talk via C, but C always has to forward packets, if A send a packet to 
B the firewall would simply block it.

However, UDP doesn't have state, a firewall can't identify connections. This 
means if you have this setup:

A ||<---->  C<---->  || B

A can get a message to B via C, then at an agreed time both A and B send a 
packet to each other. Since the firewall can only identify packets, not 
connections, A's firewall consider's B's packet a response, and vice versa. 
Then A and B have a communication channel independent of C.

This is how the STUN system works.

It's advantageous for any system to use UDP as it removes many firewall issues 
and lowers the support load.

There are other reasons to use UDP, such as real time protocols - if you drop a 
packet in a voice conversation a delay is more harmful than an audio glitch.
_______________________________________________
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe
_______________________________________________
Support mailing list
Support@freenetproject.org
http://news.gmane.org/gmane.network.freenet.support
Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support
Or mailto:support-requ...@freenetproject.org?subject=unsubscribe

Reply via email to