I'm a new to this stuff, but I want to try to get some data from an NTP/PTP device I have. The manual states this:
Requesting information from the TM2X00 is done by sending a 3 byte message to the TM2X00, using
UDP/IP, to port 7372. The three bytes, in hexadecimal, are: 0xA1 0x04 0xB2 The TM2X00 will also
respond to a broadcast to the same port.
The response packet is 80 bytes
Do I simply use a UDP send/rec program to send the text 0xA1 0x04 0xB2 via port 7372 to the IP address of the TM2X00 device? Then just listen back for a response over the same port?
I've tried sending the data but I get no response from the TM2X00 device.
Thank you.
I tried sending 0xA1 0x04 0xB2 to the TM2X00 using port 7372 and am looking for an 80 byte response from it. I don't get any response. I can use wireshark and see the data is being sent to the device but that's it. No response. I'm assuming I'm not sending the data properly.
Related
I have a simple application where I send OPUS packets from one client to other say A to B.
A reads one packet from a OPUS file, and send to B.
Again after 20ms or 30ms reads one more packet and send to B, so on..
Till now I was using RTP over UDP, so on receiving side at B, when I receive the packet, I receive complete packet. After receiving complete packet I write to a new file.
This works fine.
Now I am planning to support RTP over TCP.
A will read a complete packet from OPUS file and send to B.
When packet is received at B, it may be received as a single packet or multiple packet (tcp behaviour). My requirement is, I should buffer the data till I receive complete packet. Once I receive complete packet, I will write it to a file.
Now my question is, how do I determine the length of OPUS packet at B while I receiving, so that I can buffer it.
Do not want to use libopus etc if somehow I can avoid it. If by any means from received data, can I find out length of packet?
TCP is a stream protocol. You have two primary choices: add a length word (16 bits is enough) before each Opus packet (read length, then read packet, dealing with buffering (wait to get enough bytes for the read), or pad every Opus packet to a specific size. Opus doesn't use fixed-size packets; they depend on the content and the bitrate and quality settings.
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)
We are developing one project where we are sending UDP Packets, we are successfully able to send it. But we further want to fragment our packet if they exceed some limit. The listener with whom we have to communicate is expecting any packet of 1024 and it happens that depending on the content packet may get bigger then expected, so when it goes it should be fragmented and in the wireshark it should show as 2 messages fragments and should be reassembled at the end. I am developing in vb.net.
I am using sockets in python to send files, and I am doing a packet capture while sending these files. However, I find that each packet is 1434 bytes instead of the 1500 bytes (MTU is set at 1500 bytes on my system).
I have attached some screenshots of the packet capture. I need to send the packet at 1500 bytes rather than the 1434 bytes, can some one tell me what's going on?
TCP sends whatever-sized segments it wants to send over the wire; you can't control that from the socket layer. Perhaps the remote machine is only offering a window big enough to send 1314 bytes of data (1314 + 14 bytes of Ethernet header + 20 bytes of IP header without options + 20 bytes of TCP header without options = 1368), or perhaps the congestion window isn't open wide enough to send more data.
Furthermore, you shouldn't have to control that. TCP provides a sequenced byte stream; packet boundaries are NOT significant in TCP!
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.