1

Suppose I have a server with multiple clients (UDP). Whenever it receives a packet from a client, the server will spend 1 second processing the packet and send out that a new packet to all clients immediately after processing.

Will the server be able to do this if 10 packets arrive within 0.1 seconds? In other words, is it able to send out a new packet to each client immediately after processing the first received packet? (I have the feeling that the socket would get "clogged" up by the 9 other unread packets)

The server loop would be like:

while (1) {
    read_a_packet()
    process_packet()
    send_new_packet_to_all_clients()
}
user990814
  • 11
  • 1
  • 2

2 Answers2

1

Incoming UDP packets are put into buffer for future retrieval. If your processing is slow enough to fill the socket buffer with packets, following packets will just be discarded.

See also How does a Linux socket buffer overflow? and C++ UDP sockets packet queuing (also check out comments there).

Community
  • 1
  • 1
Roman R.
  • 68,205
  • 6
  • 94
  • 158
  • I'm not concerned with fillin the buffer but with this: If the socket buffer is partially filled, what happens when I try to send out a packet? – user990814 Oct 12 '11 at 07:22
  • You might be concerned with loss of packets when the buffer is full. As for sending packets - you are free to send them anytime, regardless of the state of socket input. – Roman R. Oct 12 '11 at 07:32
  • Ok thanks. Actually the numbers I gave were an exaggeration; in my application the processing time is in general much lower than the time between received packets, but I wanted to know what could happen if a packet was received while another was being processed. – user990814 Oct 12 '11 at 07:41
0

By your own definition, process_packet() takes 1 second to run. A thread can only do one thing at a time, so such a looping server in a single thread will take 10 seconds to process 10 packets. So either speed up process_packet() to less then 1 second, or else run multiple processing threads so you can process multiple packets in parallel.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770