The diagram below\u00a0should clarify this hierarchy a bit further:<\/p>\n
![\"\"](\"http:\/\/smartfoxserver.com\/blog\/wp-content\/uploads\/2019\/09\/protocols.png\")
<\/p>\n
We can see that TCP<\/strong> works as a reliable and ordered transport, meaning that it already makes sure that packets get to their destination in the same order in which they were sent. To do so it exchanges messages between client and server to keep track of\u00a0every packet. UDP<\/strong> on the other hand is a much simpler protocol, with no guarantee of packet delivery or ordering.\u00a0Without retransmission and delivery checks, UDP can be much faster as it doesn’t need extra state messages, but\u00a0its use is limited\u00a0to scenarios where packet loss can be tolerated (multiplayer games can be one of them).<\/p>\n Finally when we talk about protocols such as HTTP or Websocket we are already implying their underlying transport (TCP in this case). SmartFoxServer’s own protocol\u00a0can work with both TCP and UDP,\u00a0making\u00a0it more\u00a0suitable for multiplayer games, among other things.<\/p>\n After introducing the basic features of TCP and UDP you might think that only UDP is a candidate for packet loss. After all, we’ve just\u00a0shown\u00a0how TCP guarantees data delivery and therefore we would expect that protocols built on top of it (HTTP, Websocket, and SFS2X protocol) would not suffer from such issues.<\/p>\n This is mostly correct\u00a0but there are exceptions and, more importantly, the server has the last word on which packet might be discarded. To be more clear, SmartFoxServer does its best to avoid dropping packets but there are two situations in which this will happen:<\/p>\n The second scenario is the most common for TCP-based connections<\/strong> and SFS2X attempts to discard non-priority packets before anything else, to mitigate the situation. Should the queue become completely full there will be no other choice but to drop the next outgoing responses.<\/p>\n Finally as regards UDP<\/strong> the packet-loss aspect is included by design as a tradeoff for speed. Therefore, when you plan to use this protocol you should already work with its limitations in mind. Typical usages of this approach are real-time games where client-prediction and smoothing are employed to hide potential updates loss. We have mentioned that if\u00a0you’re using UDP<\/strong> you will need to assume that packets will be dropped and\u00a0include some form of compensation for it. When using TCP\u00a0<\/strong>instead, you can check your AdminTool’s Dashboard<\/strong> to see if you have outgoing or incoming dropped packets.<\/p>\n In a live environment it is expected to see outgoing dropped packets, typically in the range of 5-10%<\/strong>. Within these values you should not worry about it as there always is a minority of slower clients\u00a0that lag behind and cause the server to drop some messages. On the other hand\u00a0if\u00a0the outgoing rate is > 10-15% it’s probably best to investigate.<\/p>\n As regards incoming packets the value should always be 0%, as this only represents very large requests being\u00a0discarded. (With 500KB as the default limit very few games -if any- should ever see an incoming dropped packet).<\/p>\n Generally speaking in\u00a0turn-based games we\u00a0should always expect no packet loss or\u00a0few rare instances for very slow clients.\u00a0Instead real-time games\u00a0are\u00a0more likely to see some packet drops,\u00a0typically for users with a\u00a0 slow device or laggy network.<\/p>\n The golden rule to minimize the issue is to avoid pushing more packets than your clients can realistically process and, while there isn’t a fixed value for this approach, a general guideline is this:<\/p>\n So if you’re planning for a TCP-based action game with 30+ updates per second think twice as you’re asking too much and it will be very difficult to make it work smoothly, if at all possible.<\/p>\n The physical location of the servers plays an important role in this aspect, as a\u00a0large distance from the client adds\u00a0extra latency which in turn can reduce the packet-per-second rate.<\/p>\n Mobile connections have higher latency than regular home\/office connections. If you’re planning a mobile game you should keep this aspect into account and run some tests in advance to see what is an acceptable\u00a0pps for a mid tier phone.<\/p>\n Finally, even if it sounds obvious, dedicated hosting is the best hosting. Meaning that to run a good multiplayer game you need high quality bandwidth, which is only found from reputable hosting providers. It\u00a0should go\u00a0without saying, but we’ve had cases where this aspect wasn’t as clear as we thought it would be.<\/p>\n We hope to have clarified some of the main aspects\u00a0of\u00a0this subject so you can\u00a0improve your game performance, if necessary. If you have more questions or want to join the conversation please feel free to do so via our support forums<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" Packet loss\u00a0is a potential issue\u00a0for multiplayer games and recognizing it earlier rather than later can be very helpful in making your game more enjoyable, especially for players with sub-optimal connections. In this article we’re going to explore the different types of packet loss, how to identify the\u00a0issue and how to solve it when it appears.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[23],"tags":[108,37,107,34,96],"_links":{"self":[{"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/posts\/1169"}],"collection":[{"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/comments?post=1169"}],"version-history":[{"count":15,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/posts\/1169\/revisions"}],"predecessor-version":[{"id":1186,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/posts\/1169\/revisions\/1186"}],"wp:attachment":[{"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/media?parent=1169"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/categories?post=1169"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/smartfoxserver.com\/blog\/wp-json\/wp\/v2\/tags?post=1169"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
\nRe-transmission is also supported in case one of the two\u00a0sides didn’t acknowledge the reception of a previous packet. Finally “traffic control” allows\u00a0TCP<\/strong> to avoid saturating the bandwidth when the other side of the communication is still dealing with older messages.<\/p>\n\u00bb\u00a0Where did my packets go?<\/h2>\n
\n
\nWe have several examples of this approach, if you want to learn more:<\/p>\n\n
\u00bb\u00a0How do I know if my game is dropping packets?<\/h2>\n
![\"\"](\"http:\/\/smartfoxserver.com\/blog\/wp-content\/uploads\/2019\/09\/dashboard-stats-e1568643568680.png\")
<\/p>\n\u00bb\u00a0What can be done to minimize packet drops?<\/h2>\n
\n
\u00bb Continue the discussion<\/h2>\n