I *hate* TCP slowstart..

There has to be some better way to handle streaming audio. Oh, right, there is, UDP, but it won’t go through NATs. Where’s my TCP-with-no-sliding-window-and-no-guarenteed-arrival-order?

5 Responses to “I *hate* TCP slowstart..”

  1. ClintJCL Says:

    Wait.. is it impossible for UDP to go through NAT? If so, that would help my anti-router arguments. (I’m all static ips, all directly connected. and didn’t use firewall or antivirus until 2005 or so. and had a 2-letter vnc password.)

  2. sheer_panic Says:

    UDP can go through NAT under very specialized circumstances involving configuring a UDP port on the firewall to foward to a machine behind the firewall. UDP can not ‘ad-hoc’ through NAT the way TCP can.. NAT works by using the little-known fact that a outgoing TCP session has a source port as well as a destination port – by doing a little bit of mapping, this enables one IP address to have 64k connections. UDP is stateless – there isn’t a binding between the source and destinition, there’s no ‘start’ and ‘stop’ packets, no three-cornered handshake – you can send UDP from behind a NAT pretty easily, but getting UDP *back* to a host behind the NAT – without knowing which host should get it – is a little trickier. There’s not actually any good way that doesn’t involve manual configuration for traffic to come from the outside in with a NAT anyway.

    This is especially problimatic for services that use a fixed UDP port – because it means only one computer behind the NAT can participate in those services. Microsoft’s Netmeeting is one example, or used to be anyway. Most streaming audio systems are another example. Fortunately most p2p and game software let you set the port, so multiple workstations can participate in a game of c&c generals or leech using emule.. 😉

  3. ClintJCL Says:

    Thanks… That jives well with how I feel about it. I don’t want anything stopping me from doing anything. (That was necessarily vague.)

  4. curious Says:

    Your incorrect UDP uses source/dst ports this is how udp packets know how to get back… In fact src/dst port make up most of a UDP header. UDP just doesn’t have any sort of session/state tracking (like syn/ack). It is the lack of session/state data… looking just at the UDP headers there is no way to tell if the packet that is arriving is part of a new session or existing session… whereas with TCP just looking at the flags you can…

    Your description of UDP is completely wrong and bugs me… I don’t mind oversimplification of RFCs, but at least try to be correct 😉
    http://en.wikipedia.org/wiki/User_Datagram_Protocol

  5. sheer_panic Says:

    No, I’m not incorrect. UDP *outbound* will go through a NAT. UDP *inbound* will only go through NATs that are smart enough to apply some sort of virtual session (i.e. because machine A, behind a NAT, sent a datagram from src port 1000 to dst port 2000, if machine B sends a datagram back to src port 1000, they must have meant it for machine A) and only when there aren’t several hosts trying to use the same protocol and hence the same UDP port. *none* of the things I said were incorrect..

Leave a Reply