Udp Send and Receive socket behavior

1
votes

I am writing a program which will first authenticate to a server then send and receive messages through UDP. While sending and receiving messages, I also need to maintain the connection to the server, so I need to periodically send KeepAlive to the server and receive response from the server.

I understand it is possible to send and receive packets on the same socket at the same time, but I am concerned about the scenario where I take a while to build a packet for sending, and during that time, the server sent me two messages.

  1. When I call receive(), does the second message overwrites the first message?
  2. Is it the best practice to set up two UDP sockets for what I am trying to accomplish? one socket for sending and one socket for receiving.

Thank you, Lex

1
c#socketsudp
My first advice is to use TCP protocole in connected mode. UDP is used to broadcast or to special usage when you can loose some packet or for optimization. social.msdn.microsoft.com/Forums/en-US/… – Mr_Thorynque
Hi Mr Thorynque, Thanks for the suggestion. Unfortunately, I don't have a choice here. The server which I am interfacing with only uses UDP. – Lex L
1. Call receive() no override, but the order is not know maybe the second message is received fisrt. 2. yes one on server side and one on client side, no more. – Mr_Thorynque

1 Answers

2
votes

It is unfortunate that the server, which you say you have no control over, requires UDP and has an authentication scheme. This is a serious security problem, because it is relatively easy for an attacker to pretend to be the same UDP end point as your client which has been authenticated.

As far as your specific questions go:

  1. In a perfect world, if the server sends you two datagrams (messages) before you have tried to receive any, you will still receive both datagrams, in the order in which they were sent, because the OS has buffered them and presents them both to you in order.

The problem is that it's not a perfect world, and especially when you are dealing with UDP. UDP has three significant limitations:

  • Delivery of any given datagram is not guaranteed. Any datagram may be lost at any time.
  • Order of delivery is not guaranteed. Datagrams are not necessarily received in the same order in which they were sent.
  • Uniqueness of delivery is not guaranteed. Any given datagram may be delivered more than once.

So not only is it possible that if the server sends a second datagram, the first one may be lost if you have not received it yet, the first one may be lost in any case. You have no guarantee that any datagram will be delivered to you.

Now, there is also the issue of what you do with the datagram once you have received it. Unfortunately, it's not clear from your question whether this is part of what you're asking about. But naturally, once the call to ReceiveFrom() completes (or Receive() if you have used Connect() on the UDP Socket) and you have the datagram in hand, it's entirely up to your code how this is handled and whether previously-received data is overwritten or not.

  1. It is not best practices to create two separate UDP Socket instances, one to handle receiving and one to handle sending. Not only is it unnecessary, you would have to either have some mechanism for the server to understand that two different remote endpoints actually represent the same client (since they would normally have different port numbers, even if you guaranteed they were on the same IP address), or you would have to abuse the Socket by using the "reuse address" option (which is a way to allow the same port to be used by two different Sockets, but which leads to all kinds of other issues).

It is perfectly fine to use the same Socket instance for both receiving and sending, and in fact this is how you're expected to use it. The best practice is to do it that way.