› Forums › IoTStack › Discussions (IoTStack) › UDP is hot.
Tagged: ConnectivityTech_S8, IoTStack_G6, Tech_G15
- This topic has 1 voice and 0 replies.
-
AuthorPosts
-
-
January 6, 2019 at 12:35 pm #27607
#Discussion(IoTStack) [ via IoTForIndiaGroup ]
It is hot again for LPWAN as well. Despite all the talk, NB-IOT modules merely support UDP and TCP at best. No TLS/DTLS/HTTP/HTTPS. In metering space WiSUN (802.15.4g) solutions are also typically UDP. The combination of Weightless ACK mode with secure WebSocket between the Base Stations and the Base Station Controller proves beneficial to achieve 99% reliability. This is then backed by HTTP/2 to the backend for efficiency. For a small number of devices we are to use LTE but we had to settle for Cat1 to have a reliable HTTPS REST interface.
But moving from TCP to UDP can get you much the same performance without usermode drivers. Instead of calling the well-known recv() function to receive a single packet at a time, you can call recvmmsg() to receive a bunch of UDP packets at once. It’s still a kernel/usermode transition, but one amortized across a hundred packets received at once, rather a transition per packet.In my own tests, you are limited to about 500,000 UDP packets/second using the typical recv() function, but with recvmmsg() and some other optimizations (multicore using RSS), you can get to 5,000,000 UDP packets/second on a low-end quad-core server. Since this scales well per core, moving to the beefy servers with 64 cores should improve things even further.
BTW, “RSS” is a feature of network hardware that splits incoming packets into multiple receive queues. The biggest problem with multi-core scalability is whenever two CPU cores need to read/modify the same thing at the same time, so sharing the same UDP queue of packets becomes the biggest bottleneck. Therefore, first Intel and then other Ethernet vendors added RSS giving each core it’s own non-shared packet queue. Linux and then other operating systems upgraded UDP to support multiple file descriptors for a single socket (SO_REUSEPORT) to handle the multiple queues.
Another cool solution in QUIC is mobile support. As you move around with your notebook computer to different WiFI networks, or move around with your mobile phone, your IP address can change. The operating system and protocols don’t gracefully close the old connections and open new ones. With QUIC, however, the identifier for a connection is not the traditional concept of a “socket” (the source/destination port/address protocol combination), but a 64-bit identifier assigned to the connection.This means that as you move around, you can continue with a constant stream uninterrupted from YouTube even as your IP address changes, or continue with a video phone call without it being dropped
-
-
AuthorPosts
- You must be logged in to reply to this topic.