4 ms·

I'm interested on the author's thoughts on using solutions like ENet, which offer both reliable (TCP-like) and unreliable (UDP-like) "channels". I live somewhe

I'm interested on the author's thoughts on using solutions like ENet, which offer both reliable (TCP-like) and unreliable (UDP-like) "channels". I live somewhere where bandwidth is decent (12Mbps) but dropped packets are frequent (copper lines). Games that use UDP (TF2, CoD, NS2) work perfectly, in contrast to TCP games (WoW, Minecraft) which stutter to the point of being unplayable. In my hobby game's engine (Source Engine-inspired), I use ENet. Even with high packet loss, variable latency, and limited bandwidth (simulated) the game remains playable; whereas when all the channels are set to 'reliable', it's the opposite. Another consideration is NAT-punching. From the small amount I've read, it seems this is much easier to accomplish with UDP.

einhverfr 13y ago
Since TCP packets contain more network state information, why would NAT-punching be easier on UDP?
- JoeAltmaier 13y ago
  NAT-punching requires 1) knowing a public address for the peer, and 2) both peers able to send traffic to the other. TCP is directed - one is the server, the other the client. Not true peers. That's an extra thing to sort out with TCP. AND the server cannot attempt to talk to the client before the client talks to the server, which is a problem in 2) above.
  - einhverfr 13y ago
    TCP gives you a superset of information than what you get with UDP, so consequently you get a superset of options. There is no method of nat punching that will work on UDP that will not work on TCP. The reverse is not true.
    - JoeAltmaier 13y ago
      It works; its just far more complicated. Because its not about the IP stack at all. Its about the routers/firewalls and NAT. It goes something like this. Something called 'pinholes' are created in your router - a map between an internal address-triplet (IP:Port:Protocol) and an external address-triplet. Messages arriving from one are mapped to the other and forwarded. In addition, a third address-triplet can be used to guard against port-scanning and malicious bots etc. It's used on external (public) packets to test the Source of the packet. Its built from the 1st packet send out that created the NAT entry, from the public address target of that packet. In other words, incoming traffic is only translated and forwarded to your computer/port if it came from somebody you previously SENT a packet to, such that your NAT entry has that address as its 'filter' triplet. UDP can send arbitrary packets to anybody. TCP MUST start with a connection exchange where a client first tries to contact a server. But in our case we want them to be peers; both 'clients'. So, TCP 'pinhole' creation involves both clients simultaneously attempting to open a socket to each other. Both clients must be prepared to accept (listen) for that attempt. Initially each outgoing client connection attempt may be rejected by the peer's router - if it hasn't previously attempted to talk back to that peer yet, there is no NAT entry with a matching filter triplet. It has to be nearly simultaneous because TCP connection retry can be large, and it takes a minimum of 2 tries (one to create the NAT entry but fail arriving at the peer, the 2nd MAY succeed if the peer has also created a NAT entry at exactly the same time). Add to that, learning your public address Requires contacting some STUN/ICE style public server, which creates your NAT entry but marks it with the STUN server filter triplet. So the peer connection is actually a 2nd attempt to create a pinhole. If your router doesn't overwrite that NAT entry's STUN triplet with the peer triplet, or create a multi-way associative table entry, or incompletely updates the triplet (IP but not port or IP/Port but not protocol) then the peer's incoming client-connect will be rejected anyway. Since port-scanning and malicious bots are not in any way an official protocol, every router manufacturer invents their own algorithm for defending against them. There is no guarantee that any particular NAT-pinhole-creation technique will work every time with any particular router. So no, TCP isn't really a superset; in a real way its a much more restricted set, and p2p TCP works far less often in practice than UDP. Because for UDP you control every packet, and send to exactly the addresses in exactly the order you wish. So you have far more control over the initial exchange content and timing, and thus have more control over pinhole creation.
zurn 13y ago
Your network sounds odd: If you get 12 Mbps when blasting UDP but you experience packet loss high enough to bog down TCP, it actually sounds like your network is congested and TCP is working as designed. Your copper last mile modem (eg. ADSL2 or DOCSIS) has error correction DSP magic going on that is designed to adjust to the signal quality observed and trains the link paramters so that packet loss doesn't happen, at the expense of bandwidth. And you get a 12 MBps link speed, which sounds like your modem hasn't had to slow it down to a crawl to prevent packet loss. So congestion or other fault/misconfiguration in your ISP's access network? Custom protocols on top of UDP are also supposed to respond to congestion by slowing down. See eg http://tools.ietf.org/html/rfc5405#section-3.1 http://tools.ietf.org/html/rfc5405#section-3.1
- JoeAltmaier 13y ago
  How about router buffer overflow? UDP can survive that (because routers feel free to throw excess in the bit bucket) but TCP cannot.
  - zurn 13y ago
    That could mean two things: a) packets are arriving from a fast link and don't fit onto a slow link. Dropping packets signals TCP or your UDP protocol to adjust to the slower link speed, exactly the desired behaviour. b) the router buffer is too small to handle uneven bursts of packets even when the destination link has spare capacity. This is a misbehaviour and will cause needless packet loss. Then there's the "too much buffering" failure mode c) the router buffer is too big, so that there is constantly a long queue of packets in the buffer at the upper limit of the link speed, causing excess delay. This is also called "buffer bloat" and is a sin often committed by consumer ADSL modems and such. So, an UDP protocol with retransmission capability could possibly overcome b) at the cost of behaving counterproductively in the presence of real congestion. The remaining problems would be to estimate the actual link bandwidth, and figuring out how to retransmit the large portion of lost packets while retaining good app layer latency. But that's a rare problem to have in the network because the failure mode is so obvious (TCP stops working properly even though your network is idle). c) is much more common.

einhverfr 13y ago

Since TCP packets contain more network state information, why would NAT-punching be easier on UDP?

JoeAltmaier 13y ago
NAT-punching requires 1) knowing a public address for the peer, and 2) both peers able to send traffic to the other. TCP is directed - one is the server, the other the client. Not true peers. That's an extra thing to sort out with TCP. AND the server cannot attempt to talk to the client before the client talks to the server, which is a problem in 2) above.
- einhverfr 13y ago
  TCP gives you a superset of information than what you get with UDP, so consequently you get a superset of options. There is no method of nat punching that will work on UDP that will not work on TCP. The reverse is not true.
  - JoeAltmaier 13y ago
    It works; its just far more complicated. Because its not about the IP stack at all. Its about the routers/firewalls and NAT. It goes something like this. Something called 'pinholes' are created in your router - a map between an internal address-triplet (IP:Port:Protocol) and an external address-triplet. Messages arriving from one are mapped to the other and forwarded. In addition, a third address-triplet can be used to guard against port-scanning and malicious bots etc. It's used on external (public) packets to test the Source of the packet. Its built from the 1st packet send out that created the NAT entry, from the public address target of that packet. In other words, incoming traffic is only translated and forwarded to your computer/port if it came from somebody you previously SENT a packet to, such that your NAT entry has that address as its 'filter' triplet. UDP can send arbitrary packets to anybody. TCP MUST start with a connection exchange where a client first tries to contact a server. But in our case we want them to be peers; both 'clients'. So, TCP 'pinhole' creation involves both clients simultaneously attempting to open a socket to each other. Both clients must be prepared to accept (listen) for that attempt. Initially each outgoing client connection attempt may be rejected by the peer's router - if it hasn't previously attempted to talk back to that peer yet, there is no NAT entry with a matching filter triplet. It has to be nearly simultaneous because TCP connection retry can be large, and it takes a minimum of 2 tries (one to create the NAT entry but fail arriving at the peer, the 2nd MAY succeed if the peer has also created a NAT entry at exactly the same time). Add to that, learning your public address Requires contacting some STUN/ICE style public server, which creates your NAT entry but marks it with the STUN server filter triplet. So the peer connection is actually a 2nd attempt to create a pinhole. If your router doesn't overwrite that NAT entry's STUN triplet with the peer triplet, or create a multi-way associative table entry, or incompletely updates the triplet (IP but not port or IP/Port but not protocol) then the peer's incoming client-connect will be rejected anyway. Since port-scanning and malicious bots are not in any way an official protocol, every router manufacturer invents their own algorithm for defending against them. There is no guarantee that any particular NAT-pinhole-creation technique will work every time with any particular router. So no, TCP isn't really a superset; in a real way its a much more restricted set, and p2p TCP works far less often in practice than UDP. Because for UDP you control every packet, and send to exactly the addresses in exactly the order you wish. So you have far more control over the initial exchange content and timing, and thus have more control over pinhole creation.

zurn 13y ago

Your network sounds odd: If you get 12 Mbps when blasting UDP but you experience packet loss high enough to bog down TCP, it actually sounds like your network is congested and TCP is working as designed. Your copper last mile modem (eg. ADSL2 or DOCSIS) has error correction DSP magic going on that is designed to adjust to the signal quality observed and trains the link paramters so that packet loss doesn't happen, at the expense of bandwidth. And you get a 12 MBps link speed, which sounds like your modem hasn't had to slow it down to a crawl to prevent packet loss. So congestion or other fault/misconfiguration in your ISP's access network? Custom protocols on top of UDP are also supposed to respond to congestion by slowing down. See eg http://tools.ietf.org/html/rfc5405#section-3.1 http://tools.ietf.org/html/rfc5405#section-3.1

JoeAltmaier 13y ago
How about router buffer overflow? UDP can survive that (because routers feel free to throw excess in the bit bucket) but TCP cannot.
- zurn 13y ago
  That could mean two things: a) packets are arriving from a fast link and don't fit onto a slow link. Dropping packets signals TCP or your UDP protocol to adjust to the slower link speed, exactly the desired behaviour. b) the router buffer is too small to handle uneven bursts of packets even when the destination link has spare capacity. This is a misbehaviour and will cause needless packet loss. Then there's the "too much buffering" failure mode c) the router buffer is too big, so that there is constantly a long queue of packets in the buffer at the upper limit of the link speed, causing excess delay. This is also called "buffer bloat" and is a sin often committed by consumer ADSL modems and such. So, an UDP protocol with retransmission capability could possibly overcome b) at the cost of behaving counterproductively in the presence of real congestion. The remaining problems would be to estimate the actual link bandwidth, and figuring out how to retransmit the large portion of lost packets while retaining good app layer latency. But that's a rare problem to have in the network because the failure mode is so obvious (TCP stops working properly even though your network is idle). c) is much more common.