UDP Protocol Implementation

[RobbieJack]

I'm currently migrating a program I already have which is currently using a TCP base architecture but the server currently needs to send more packets per minute than before. The packet loss is not a problem, only the order which is solved by using a message buffer.

What I have so far:

• A Client/Server Application, where each module keeps sending data packets back and forth
• The server can have up to 10 clientsEach client sends 50 p/s
• The server sends 50 packages per second times the number of clients
• Each packet can have up to 10k bytes
• The server is thread based, so non blocking.
• The clients never communicate between each other, only by server mediation.

Now my main concerns while moving to UDP are:

Should the server have only 1 socket? If so, does this mean that every client will be sending their information through that socket? It seems there will be a huge bottleneck as every info will pass over this one hole.In order to solve the latter, do I need to use 1 port for each client in the server side? If so, do I need to have 1 central port for the first "connection" between client and server and then proceed to redirect the client to its specific port, thus having multiple ports, as many as clients?

I've never implemented such protocol, so I might be missing something, and there's very few info on such complex matter.

If there are any other things I should have in consideration, I appreciate any suggestions

Regards

 

[Gryz]

This is not a forum where you should ask these question.
The usual questions are: "my WiFi is slow, help!" or "what router should I buy for my 20 Mbps connection to my shitty ISP".
But you're lucky, I'm here.

I suggest you should use TCP anyway.
Maybe there is a real reason that you can't use TCP. But usually people think "TCP is overkill". They want something "simple". But once they start working on their own protocol, they realize that UDP is lacking something they could use. And they'll implement that. E.g. sequence-numbers for ordering. So they implement that. Then they figure out that data gets corrupted, so they start using UDP checksums. Then they realize their application is dropping too many packets, so they need some form of flow-control. So they implement that. In the end, they have just re-implemented all features of TCP. Only in a less optimal way, with new bugs. If there is some reason you absolutely can't do TCP, then use UDP. In all other cases, I strongly suggest you use TCP. It has so many advantages over UDP, TCP is the right solution in 99.99% of all cases.

Some games, like e.g. WoW use TCP in stead of UDP. Maybe that's proof for you that TCP isn't always bad.

One of the main advantages of TCP is that you can get it through firewalls and NAT-boxes. Many firewalls will block all UDP traffic they don't know. That is one reason that almost all new protocols are developed on top of SSL on top of TCP. You get encryption and authentication for free, and you can get through firewalls and NAT. If you have to implement solutions for that yourself on UDP, you will wish you had chosen for TCP.

To answer your questions:
- If you use UDP, indeed the server will receive all datagrams on a single socket. I think you can control the receive queue-depth with the SO_RCVBUF setsockopt call. But do you know how much bufferspace you need in advance ? Will the requirements stay the same ?
https://stackoverflow.com/questions/2090850/specifying-udp-receive-buffer-size-at-runtime-in-linux
If you use TCP, you'll get a separate receive-buffer per connection. Which is also configurable via setsockopt(), btw. So TCP would solve one of your questions.
Or you can open a UDP socket per client, with a different port-nr. But that' s a pain. Now you have 10 clients. You might have a 100 later. Or more. Also, if you have to configure firewalls or poke a hole in NAT, you now need to open a range.
Of course you can do 1 well-known port, and then let each client send a packet to that, and give it a designated portnr for the real connection. That's almost like a TCP listen-port. Also, what do you do when that first request gets dropped ? You need to implement retrying, etc.

Another thing you probably don't realize is the fact that you are sending 10k messages. Most networks are ethernet. Most networks have a IP-MTU of 1500 bytes. Or less. If you send a 10k application-level msg, it will be fragmented into 7 UDP datagrams. The receiving UDP-driver needs to collect all fragments and re-assemble them into the original msg. If one fragment gets lost, the whole message is lost. And worse, as there are no timers involved with UDP, the IP-driver on the receiving end will need to keep the fragments "for some time". On Linux this is 30 sec by default, I believe. So if 1 fragment drops, the receiving kernel might keep 6 fragments in memory for 30 seconds. If you get some packet-loss, these numbers might add up quickly. Wasting kernel memory. That might cause other problems. Large UDP-messages are considered a no-no.

Imho, you should use TCP. That makes the networking part easy. Then you should put your energy and efforts in doing some home-brew rate-limiting when the clients send traffic. E.g. you set the TCP receive-window reasonably low. Say 20k, so you can send 2 messages always. If there's a network problem, writing the 3rd msg will block with EWOULDBLOCK. You can keep track of that, and do an estimate at what speed you can send new message without problems. This might seem a lot of work (and it is) and it's not simple. But if you use UDP you will end up with implementing something resembling flow-control anyway. When using TCP, it'll be a little easier, imho.

If you have more questions, feel free to ask.
This stuff is 10x more interesting than the usual questions here.

 

[JackMDS]

There are questions that in order to provide answer much more info about the specific system is needed.

Then the answer might need a write of few pages.

As a result (while in online forum format), it is better that the OP would be engaged in deeper self education, then (if needed) would ask for some very specific issue that can be solved in few short paragraphs.

https://www.lifesize.com/en/video-conferencing-blog/tcp-vs-udp

https://www.bleepingcomputer.com/tutorials/tcp-and-udp-ports-explained/

https://www.keycdn.com/support/udp-file-transfer/

 

[Gryz]

RobbieJack, did we answer your questions ? We're curious what you are going to do.