1

If I have a UDP server that handles incoming requests with recvfrom, processes the requests that come in (possibly time consuming), possibly sends back a response, and then calls recvfrom again, is it better to create a new sock_fd with the information in sockaddr* from to send the response back with or to use the server's sock_fd to send a response?

Basically, the question is do I want the overhead of having to create a new sock_fd, or do I want my server to be able to handle requests without having to wait to send the previous request a response.

I can't decide based on the application's needs, because this will be used in a library (hence I don't know whether there will need to be a response or not, and how long it will take to process the request).

I fail to see how this is not a real question. The question is clearly asked in the bolded section above, and in the last part of the first sentence

Eliezer
  • 7,209
  • 12
  • 56
  • 103

2 Answers2

4

There is no need to create a new sock_fd as the one which is created will have already done a bind call as its a server.

Also you have to ensure that the clients are not waiting for a response in a blocking recvfrom .

Most servers send out some error codes if they cannot give a proper response and the clients do a repeat request or something depending on that error code, may be you need to design the protocol in request-response way.

If processing is a problem hen you can always have the data + struct sockaddr of client in a queue and defer processing by signalling a thread to wakeup, by doing so your listening thread can come back to recvfrom fast, and then you can send the response from the processing thread to the saved struct sockaddr of client when you are finished.

hiteshradia
  • 357
  • 2
  • 9
  • I'm not designing any protocol here. I'm writing a library so that C++ users can use sockets in a more Java like OOP paradigm. The problem is that if I'm handling a request received on this sock_fd I can't use it to `recvfrom` until it is done processing whatever request came in first. A user of this library could have processing needs that range from microseconds to a potentially unlimited amount of time. If I tie the sock_fd up in waiting for that before I could get back to `recvfrom` I would have a pretty unresponsive server – Eliezer Feb 21 '13 at 10:01
  • sure you can use the same `sock_fd` again for receiving from other cleints. its UDP and you have not done `client_sock_fd = accept(...)` call(as in TCP) to get the clients sockfd. here you will ony need `struct sockaddr of client ` to reply back later when you need. – hiteshradia Feb 21 '13 at 10:10
  • I understand that, but I would like the amount of time between calling `recvfrom` to be as small as possible. At the same time, I want to be able to send out a response as soon as possible. – Eliezer Feb 21 '13 at 10:20
  • Are you saying that while I am blocking on `recvfrom` another thread could call `sendto` using the same sock_fd that is being used in `recvfrom`? – Eliezer Feb 21 '13 at 10:21
  • yup . sockets are thread safe and use different buffers for send and recv. read [here](http://stackoverflow.com/questions/1981372/are-parallel-calls-to-send-recv-on-the-same-socket-valid) – hiteshradia Feb 21 '13 at 11:07
0

do I want the overhead of having to create a new sock_fd

No.

or do I want my server to be able to handle requests without having to wait to send the previous request a response.

Nobody has to wait to send a message over a UDP socket. You can handle every incoming request on a separate thread if you like, and they can all call sendmsg(), simultaneously if necessary.

You definitely only want to use one socket. For one thing, it will mean that the reply will get back to the client with the same source-address information that they sent it to, which will be less confusing all round.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • I get what you're saying about the reasons not to use a new sock_fd, but I don't understand what you're saying about not having to wait to send a response. If I have a UDP socket that provides a service to many clients, I could have multiple requests to the socket. Let's say I receive req1. I now have some code that processes it. I may need to send a response to its initiator. Let's say that takes 5 seconds. I then loop back to the beginning and call `recvfrom` again. During those 5 seconds (and it could potentially be longer) I wouldn't be able to receive new requests (req2, req3, etc) – Eliezer Feb 21 '13 at 09:56
  • I've answered that. If your request/response cycle takes an appreciable amount of time that's a reason to despatch each one in a separate thread, but it's not a reason to use another socket. – user207421 Feb 22 '13 at 02:01
  • Don't mean to beat a dead horse but I do not know how long anything will take, or for what purpose the sockets will be used. I'm writing a library. It could be used in whatever way the user decides. In any case, hiteshradia explained it better in his answer; I was unaware that `sendto` can be called in one thread while `recvfrom` is blocking in another. – Eliezer Feb 22 '13 at 06:36
  • @Eliezer If you don't know how long anything will take, use threads. As to the rest of this, it's impossible for other people to know what it is that you don't know, but I said above that nobody has to wait. I don't know what else that could possibly mean. – user207421 Feb 22 '13 at 18:03
  • Let's assume I will never use this library. Someone else in the future, can use it to write networking code with a simple interface. I don't care about how they will handle different scenarios. All I care about is whether I should create a new socket to `sendto` that I can return to the user when a UDP request comes in, or if I should give them the same socket the request came in on. hiteshradia got back to me before you did, and was much clearer once I explained my situation. You were much more vague in your response. I don't mean to attack you here, only explaining – Eliezer Feb 22 '13 at 21:44
  • @Eliezer Your explanation doesn't hold water. The other response was even vaguer, and specifically it didn't mention anything about nobody having to wait to send, until you asked him. – user207421 Feb 22 '13 at 22:07
  • something he said made me realize that – Eliezer Feb 24 '13 at 01:15