I want to receive UDP packets continuously from the port. I'm using recvfrom() to receive packets. How to put delay after receiving a single packet. I want to receive more than 50 packets. For that I need help. Thanks in advance....
The network stack captures all packets addressed to the socketaddress on the line for you and puts it in a queue. Just use recvfrom to read the queued data. If you want you application to wait for the next receive event you can use the select function.
Related
I have 1 server and several (maybe up to 20) clients. All clients are sending UDP datagram at random time. Each datagram is quite short (about 10B), but I must make sure all the data from each client is received correctly.
If I let all clients send datagram to the same port, and client B sends it datagram at the exact time when the server is receiving data from client A, it seems the server will miss the data from client A.
So what's the correct method to do this job? Do I need to create a listener for each of the 20 clients?
When you bind a UDP socket to a port, the networking stack will allocate a buffer for a finite number of incoming UDP packets for you, so that (assuming you call recv() in a relatively timely manner), no incoming packets should get lost.
If you want see your buffer size in terminal, you can take a look at:
/proc/sys/net/core/rmem_default for recv
and
/proc/sys/net/core/wmem_default for send
I think the default buffer size on Linux is 131071B.
On Linux, you can change the UDP buffer size (e.g. to 26214400) by (as root):
sysctl -w net.core.rmem_max=26214400
You can also make it permanent by adding this line to /etc/sysctl.conf:
net.core.rmem_max=26214400
Since each packet is only 10B, shouldnt be a problem.
If you are still worried about packet loss you could implement a protocol where your client waits for a ACK from the server or it will resend. Many protocols use such a feature, but this is only possible if timing allows it. For example in streaming data it is not useful because there is no time to resend.
or consider using tcp ( if it is an option)
My program listen to incoming message using TCP.
In order to support incoming of multiple messages, separated by new line delimiter, I'm adding the following at the beginning of the pipeline –
New DelimiterBasedFrameDecoder(256, Delimiters.lineDelimiter())
The above is working great with TCP. Multiple messages are separated as expected.
The problem is that the code doesn't work with UDP.
Any idea?
TCP is a connection oriented stream over an IP network. It guarantees that all sent packets will reach the destination in the correct order. UDP Communication is datagram oriented, this datagrams reach destination and can arrive out of order or don't arrive at all. I think that is you problem.
If the sender uses sendto() for a few times, and receiver uses recvfrom() in a while loop, when the 2nd datagram arrives before the receiver finish processing the 1st one, will it get lost?
It depends on your architecture,driver.
The packets that arrive at receiver are normally placed in driver's receive queue and processed accordingly like passing to IP layer's queue(based on architecture). If there is any overflow here, then it will be dropped at driver itself or IP layer. However, if has passed those layers but if the receive socket buffer(the amount of space for UDP queued in UDP socket) is full, then the UDP packets will be dropped else it will not be dropped.
netstat is one of the handy tool in such scenarios. netstat -s shall list statistics protocol-wise. The -p option can be used to display for specific protocol.
If you want a proper synchronization between sender and receiver, it shall be feasible only if receiver intimates sender by some means (or some kind of flow control mechanism). UDP protocol does not support it. If you are looking for such synchronization, then you need to select TCP protocol.
In the Openflow 1.3.3 spec you have the Receive Dropped and Receive Overrun Errors counters for a port. What are the conditions when these 2 counters increment?
Thanks
Receive Overrun Errors: This warning is is related to load on the COM port and the CPUs ability to service the COM port interrupts (ie. CPU load and interrupt priorities).
Receive Dropped: I think this increments when a switch receives a packet but it drops. In other words, it receives a packet but it doesn't forward it to any of it port.
Edit:
Here is what I think:
Note that there is 2 Received Packets counter.
Received Packets Per Flow Entry. So it is incremented when a packet is received and it is matched to that flow.
Received Packets Per Port: This one doesn't care what flow it is going to match with. If a packet is received in a port, increment it.
Receive Dropped is per port. So Receive Dropped should always be less than or equal to Received Packets.
I have an application that transmits some data in a loop.
Underlying protocol is UDP on WinSock. If I don't add sleep(1ms) after each transmit operation most of the data is not sent (or wireshark can not capture it) Have you experienced such a behavour that UDP does not handle repetitive sending in a loop ?
Regards
Tugrul
First thing you should check the return values when you send data to check if data is successfully sent or not.
Second thing, This can happen internal buffer of UDP cannot accommodate more data because previous data is yet not transmitted. So the simplest solution is that each time before send the data you should check if your UDP socket is writable or not. You can do it by calling "select" or "poll" on that UDP socket.