Im using UDP packets and I want to be cleared about some points :
1 - what exactly does "recvfrom" Returns ? I mean if i send a packet with size of 450 byte + 20 byte of IP header + 8 byte UDP header does recvfrom returns 478 bytes as a whole or there could be something like :
it received 10 bytes,300 bytes,100 bytes,68 bytes ?
2 - does the return value of "recvfrom" related to packet fragmentation ?
note :
* Im talking with the assumption that "recvfrom" was successful
* I chose 450 byte to be sure that Im less than the min MTU
For an UDP socket, recvfrom() reads the UDP data. So it returns 450 , provided you supply a buffer that is at least 450 bytes big.
If you supply a buffer that is smaller than the received data, the data will be truncated, and recvfrom() will read as much data as can fit in the buffer you give it.
The IP layer will be the part that fragments an UDP packet, on the receiving host it will reassemble it. This is transparent to the sending/receiving application.
Related
I am playing around with a PIC16F1455, using the USB port based on this article: https://www.codeproject.com/Tips/530836/Csharp-USB-HID-Interface
I send data to the port, and I set the packet size (Configuration descriptor) to 8 bytes.
However, the PC sees the Capabilities.InputReportByteLength as 9 bytes
And when I receive I get 9 bytes, the first one always being 00, followed by the 8 bytes I send from my device.
Can anyone tell me why this happens?
And this first 00, what is this used for?
Can I put something real there?
I am working on a project with a master computer connected via a CANOpen network to 4 slaves.
At each time step, the computer receives a measurement message from each slave, and sends them a control message. In total, 4 messages are received and 4 messages are sent at each time sample.
The message sent is a PDO with 6 data bytes (8 bytes including COB-ID)
The message received is a PDO with 8 data bytes (10 bytes including COB-ID)
My CAN network is configured at 1Mbit/s, and I run my program at 1000 Hz (1 ms sampling time). As the total load resulting from the messages described is 576 bits/cycle, the total load expected in the network is 576kbit/s, or 57%.
What I see, however, is that:
The controlling computer measures a load of ~86% (with minima of 68% and peaks of 100%).
A USB CAN bus analyser I connect to the network registers a traffic
of messages (count-wise) that is around half of what I nominally
expect (i.e., 4 sent, 4 received each cycle, for 50 seconds should result in 50k messages, while I only see 18-25k). Moreover, I receive
1-2 error messages per cycle from the slave devices that the
network is overloaded. Before it is pointed out, even counting the
size of these messages as part of traffic wouldn't get close to
explain the anomaly in load.
What I'd like to know is whether my way of calculating the CANOpen network load is correct. For instance, are there any protocol-specific handshakes, CRCs, or any sort of extra bytes sent to make the network simply work? It's nothing I could see in the wiki page of CANOpen, but I do know there are such appendices to messages in the original CAN bus standard.
In a CAN message, there is more than the data to be transmitted.
There is also the arbitration ID (11- or 29bits, depending on whether you use CAN 2.0A or 2.0B), there is a 15 bit CRC, an 7 bit EOF marker, the control field and also some other reserved bits.
Depending on the data, there may also be stuff bits.
Using CAN2.0B and assuming 48 bits (6 bytes) of data, you will get a message size of roughly 132 bits and roughly 151 bits for your 64 bits messages.
Summing this up, you will get roughly 1132 bits per cycle which is too much for a 1Mbit/s bus and 1000 Hz.
Hope that helps.
The gnuradio UDP Source block has a default Payload Size of 1472. The documentation indicates
"payload_size : UDP payload size by default set to 1472 = (1500 MTU - (8 byte UDP header) - (20 byte IP header))"
My C client program sends packets of 16 bytes to the gnuradio udp source once every second.
Should I set the MTU value to 16?
Thank you.
No, the Payload Size refers to the maximum packet size that can be handled by the block. However, the block then handles your 16 byte as a stream, so if you like to keep this packet form additional steps are required.
Say that A sends B a UDP message of size N like
sockaddr_in to;
to.sin_family=AF_INET;
to.sin_port=htons(port);
to.sin_addr.s_addr=inet_addr(address);
sendto(sock,(const char*)buffer,N,0,(sockaddr*)&to,sizeof(to));
Now B receives this message expecting it to be of size N_1
sockaddr from;
socklen_t length_from=sizeof(from);
recvfrom(sock,(char*)buffer,N_1,0,&from,&length_from);
What happens when N_1!=N ?
What happens when N_1!=N ?
If the receive buffer is larger than the incoming datagram, the entire datagram is transferred into the buffer and the actual length is returned as the return value of recfvrom(). You're presently ignoring it. Don't do that.
If the receive buffer is smaller than the incoming datagram, it is truncated to fit into the receive buffer and he excess beyond that is discarded. The actual length of data transferred into the buffer is returned.
I want to read specific number of bytes from udp socket. In tcp socket I can use socket.read where I can specify the amount of data to receive. I don't find similar function for UDP socket. I am using receive_from() where I can specify the amount of data to read, but if there is more data then no data is read and I get following error.
"A message sent on a datagram socket was larger than the internal message buffer or some other network limit, or the buffer used to receive a datagram into was smaller than the datagram itself" std::basic_string<char,std::char_traits<char>,std::allocator<char> >
I am not able to find what value do I need to give for message_flags (3rd arg to receive_from) so that it will read the number of bytes specified. Currenly I am using the following code to read data but it either reads all data or no data.
size_t size=socket.receive_from(boost::asio::buffer((const void*)&discRsp,sizeof(DataStructure)),remote_endpoint,0,errors);
Try this:
socket.set_option(boost::asio::socket_base::receive_buffer_size(65536));