{"id":1274,"date":"2020-03-02T11:24:04","date_gmt":"2020-03-02T11:24:04","guid":{"rendered":"https:\/\/smartfoxserver.com\/blog\/?p=1274"},"modified":"2020-03-02T17:30:20","modified_gmt":"2020-03-02T17:30:20","slug":"sfs2x-2-15-0-udp-update","status":"publish","type":"post","link":"https:\/\/smartfoxserver.com\/blog\/sfs2x-2-15-0-udp-update\/","title":{"rendered":"SFS2X 2.15.0, UDP update"},"content":{"rendered":"\n

SmartFoxServer 2.15.0 provides several improvements for scaling the UDP protocol to uber-high packet rates, which can be useful for real-time games with massive traffic that use very fast updates (e.g. 30 or 50 packet\/s).<\/p>\n\n\n\n\n\n\n\n

\u00bb Background<\/h2>\n\n\n\n
\"\"<\/figure><\/figure><\/div>\n\n\n\n

During the month of February 2020 we were contacted by a customer, running a large online multiplayer game, reporting a potential bottleneck<\/strong> when scaling UDP traffic over a certain point. In particular the problem seemed related more with packet rates (or pps) rather than bandwidth.<\/p>\n\n\n\n

After some investigation we confirmed the customer’s findings that threads were blocking on the same DatagramChannel<\/strong> object, causing UDP writes to work serially rather than in parallel (a DatagramChannel is essentially a Java abstraction for a UDP connection between two endpoints).<\/p>\n\n\n\n

We found this aspect particularly surprising because of the general design of the Java NIO API and because it seems a largely overlooked “feature” of the Java non-blocking UDP implementation, even among experts (if you want to learn more details about this post from our forum<\/a>).<\/p>\n\n\n\n

\u00bb Multiple iterations<\/h2>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n

To fix this issue we had to dive deep into the guts of Java’s non-blocking API to see exactly which of the many possible solutions would be the best to get rid of potential bottlenecks.<\/p>\n\n\n\n

We stacked up the standard SFS2X implementation against multiple prototypes to see the differences:<\/p>\n\n\n\n

  1. Non-blocking UDP w\/ DatagramChannel cache (to avoid thread contention)<\/li>
  2. Non-blocking UDP w\/DatagramChannel cache + dedicated thread pool and message queue (implementing a more aggressive write-policy for UDP, compared to TCP)<\/li>
  3. Old school blocking UDP + dedicated thread pool and message queue<\/li><\/ol>\n\n\n\n

    Running all these tests on a dedicated quad-core Xeon server we found that the standard SFS2X implementation (v2.14.0) would max out at ~215Kpps while there was plenty of CPU available to keep going.<\/p>\n\n\n\n