Stories
Slash Boxes
Comments

SoylentNews is people

posted by on Monday January 02 2017, @08:09PM   Printer-friendly
from the which-packet-is-right-for-you dept.

An introduction to networking for game programmers:

Hi, I'm Glenn Fiedler and welcome to the first article in my article series Networking for Game Programmers

In this article we start with the most basic aspect of network programming, sending and receiving data over the network. This is just the beginning – the simplest and most basic part of what network programmers do, but still it is quite intricate and non-obvious as to what the best course of action is. Take care because if you get this part wrong it will have terrible effects on your multiplayer game!

You have most likely heard of sockets, and are probably aware that there are two main types: TCP and UDP. When writing a network game, we first need to choose what type of socket to use. Do we use TCP sockets, UDP sockets or a mixture of both?

The choice you make depends entirely on what sort of game you want to network. So from this point on, and for the rest of this article series, I'm going to assume you want to network an action game. You know games like Halo, Battlefield 1942, Quake, Unreal, CounterStrke, Team Fortress and so on.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Informative) by wisnoskij on Monday January 02 2017, @08:44PM

    by wisnoskij (5149) <{jonathonwisnoski} {at} {gmail.com}> on Monday January 02 2017, @08:44PM (#448639)

    Just read the linked article.
    Basically, TCP is heavily abstracted, and built for non-time sensitive applications. It has built in support to check for and resend missed packets, so loads of overhead.
    UDP is just a tiny layer on top of the base IP-packet stuff, and works just like the underlying tech, allowing you to send packets of information to an address.

    Both are protocols designed for passing information over the Internet. If your MPI works over an intranet, it might use something completely different? At least when you are talking about passing information over single physical cables, I imagine their are better ways then the use of Internet networking protocols.

    Starting Score:    1  point
    Moderation   +1  
       Informative=1, Total=1
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 4, Informative) by VLM on Monday January 02 2017, @10:21PM

    by VLM (445) Subscriber Badge on Monday January 02 2017, @10:21PM (#448667)

    You got some minor details wrong that don't matter much, but it is interesting that UDP adds little to no latency to an overall path which is important if 28.8 modems are still an ongoing concern. It doesn't really add much overhead unless you're running at 1200 baud like AX.25 stuff I did in the 90s, the killer is latency from the lossless retransmission of TCP.

    If what you need is about the size of the pipe then reimplementing 90% of TCP on top of UDP without reordering and retransmission is worth the extraordinary programming effort. However as pipe speeds increase its eventually a waste of time. I'm not really a FPS guy but I imagine TCP over a multi-meg connection is fine in 2017.

    For example I assume video is still streamed over UDP as is NFS access. However a fast downloading torrent can in 2017 download faster over TCP than you'll be playing it anyway so no longer an issue. Another example is console sessions need 2400 baud or 9600 baud or so depending on your reading speed and demands for screen refresh (and screen size I guess) so 1200 baud is a bit low while 2400 is adequate for a text mode UI. Anyway using TCP over a 28.8 modem or multi-meg cablemodem or DSL to a MUD or big computer isn't a problem because your session bandwidth is like 1% or maybe as much as 10% of the pipe bandwidth, where you need crazy homemade "almost TCP but faster and cruder" is when you want to shove 99.9% of the pipe for your one session.

    TCP can get very cloggy when you ask for more than maybe 50% of the pipe bandwidth. Not unusable but can get really weird. Especially with multiple sessions on that pipe.

    There was another perhaps intermediate fad of "we gonna run everything over port 80 because dumb misconfigured firewalls"

    I didn't read all the articles. Used to be a black art craft to punch UDP thru NAT firewalls reliably. Now you "probably" link in the proper library for uPNP or WTF its called and its all good.

    There was also an era of "well better run on both UDP or TCP to increase odds of victim getting it to work. From memory the PC minecraft version uses UDP or TCP and works fine with only TCP port forwarding while the pocket edition uses UDP only just to be different.

    Since the article was written, or since the issue came up a decade before the article was written, there have been about 50-bazillion attempts at a "more than UDP but less than TCP" protocol for streaming video or gaming. Most of them not getting very much of anywhere, mostly.

    If you want to add some fun like moths to a flame multicast networking has been wasting programmer time since the 80s and never really getting much of anywhere either.

    Everything network-ish is like ISDN to some extent or another in that 99% of people use 1% of its capabilities and there are all kinds of weirdness in the dark recesses. Actually most closed source software is like that, if its got a marketing driven checkbox list most of it is invariably non-useful, non-usable, and buggy.

    • (Score: 2) by VLM on Monday January 02 2017, @10:27PM

      by VLM (445) Subscriber Badge on Monday January 02 2017, @10:27PM (#448670)

      Oh and I forgot to mention the "fun" of SSL stream encryption working quite well on an ordered and guaranteed TCP session and being more of a challenge over a UDP "session".

      And I forgot to mention the hilarity of "protocol designerz" trying babbys first secure system without even knowing what MITM means. That may be the most interesting change over the last couple decades is assuming that someone powns at least one of the endpoints and is MITM you continuously now try to implement something that doesn't benefit cheaters or can't be messed with using a simple proxy.

      That covers about all I can think of off the top of my head about trends in network programming over the last 30 or so years, since the dominance of TCP/IP. I don't like talking about the bad days of IPX/SPX Novell or SNA or X.25. Battle fatigue I guess. Fing SNA over X.25 over frame relay, WTF cubed.

    • (Score: 2) by wisnoskij on Monday January 02 2017, @10:39PM

      by wisnoskij (5149) <{jonathonwisnoski} {at} {gmail.com}> on Monday January 02 2017, @10:39PM (#448677)

      Bandwidth is not that big of a concern, it is more about ping. Absolute best is still the speed of light between locations, and even that can get annoyingly slow when you are talking about playing halo with someone across an ocean. And when the server has to wait for you to resend packet 29 before it delivers anything else, that can cause many problems.

      The way I think of it:
      TCP is a file transfer protocol.
      UDP is when you want to virtually connect your keyboard/ect to another computer. More generally this is the protocol you use then ping matters more than any other metric.

      • (Score: 3, Informative) by VLM on Monday January 02 2017, @10:54PM

        by VLM (445) Subscriber Badge on Monday January 02 2017, @10:54PM (#448687)

        Ironically the "legacy" pre-PS/2 and PS/2 hardware keyboard interface are synchronous bidirectional serial and USB is error correcting also. Also SSH is how I connect over TCP to most all consoles now a days.

        A good example along your lines of UDP for UIs "send it and hope it arrives" is some of the mostly-write-only video card hardware interfaces over the past couple decades. Like before PCI, the "special" stuff like AGP and weirder. Those truly were some write only, hope it gets there, protocols.

      • (Score: 3, Insightful) by pe1rxq on Tuesday January 03 2017, @12:01AM

        by pe1rxq (844) on Tuesday January 03 2017, @12:01AM (#448704) Homepage

        Sending keyboard (or other input) events over UDP is generally a bad idea.

        What will your commands do if a few packets with crucial characters went missing? (e.g. 'rm -rf /lib' instead of 'rm -rf ./lib')
        Or the result in your text editor when a key-up event goes missing? (For extra drama make it the backspace key-up)

        • (Score: 0) by Anonymous Coward on Tuesday January 03 2017, @02:30AM

          by Anonymous Coward on Tuesday January 03 2017, @02:30AM (#448740)

          This is not the use case for UDP.

          This is: you shoot a bullet in an FPS. Your key press gets lost on the network, you utter a curse on the gun and pull the trigger again. In the worst case, your avatar got shot in the mean time and you respawn.

    • (Score: 2) by driverless on Tuesday January 03 2017, @02:56AM

      by driverless (4770) on Tuesday January 03 2017, @02:56AM (#448751)

      Great summary! It's interesting that you mention performance considerations in regard to dialup modems and the like, there's a lot of historical baggage around TCP vs. UDP that dates back to fuzzball routers and 2BSD and similar, before every NIC had hardware offload and every router was done in ASICs (at least for the fast path) that operated at the full line rate. So in many cases where the historical wisdom was that you did it in UDP, it's now perfectly OK to do it with TCP. In particular, as you point out, reimplementing 90% of TCP, inevitably done badly because you have to rediscover 40-odd years of TCP optimisation and tuning each time you do it, using UDP is never a good idea.

    • (Score: 2) by TheRaven on Tuesday January 03 2017, @12:09PM

      by TheRaven (270) on Tuesday January 03 2017, @12:09PM (#448864) Journal

      the killer is latency from the lossless retransmission of TCP

      Close. The real killer is the ordering guarantee. TCP provides a stream interface. If a packet is dropped in a TCP flow and needs to be resent, then this delays all of the packets after it. In a game, you typically want the most recent world state. If you miss a packet, then things will jump a bit, but if your packets are delayed then you'll have a smooth appearance of motion but the server won't agree where the objects are (e.g. I shoot a rocket, it hits someone, but then the server tells me that the person was a metre to the left and now suddenly they're unharmed).

      If what you need is about the size of the pipe then reimplementing 90% of TCP on top of UDP without reordering and retransmission is worth the extraordinary programming effort

      This and TFA present a false dichotomy. The correct answer in most cases is SCTP [wikipedia.org], which provides a message-oriented protocol with most of the advantages of both TCP and UDP. It's pretty widely supported, including a pure-userspace implementation that works pretty much everywhere for the platforms that don't have native support.

      For example I assume video is still streamed over UDP as is NFS access

      NFS has supported TCP for a while, and it's generally a good idea (UDP is easier to spoof: with TCP you have to be able to receive packets at the address that you claim to be sending them on to do the initial handshake and if you want to hijack an existing connection then you must be able to predict the sequence numbers). Video streaming for watching films is typically done using TCP downloads of 1MB chunks. The client buffers them and fetches the next ones as the movie plays. Chat apps often use UDP.

      --
      sudo mod me up