Occasionally splitting large UDP datagrams?
I'm having a bit of trouble sending UDP datagrams with vxWorks 5.5 on
an MVME5500. I'm hoping someone else has seen this and can tell me "you
dope, you need to set this obscure socket option".
As the target runs, the application generates periodic UDP datagrams
describing its current state. Each datagram contains 1880 bytes. The
frequency of these updates can be controlled by the client, which is
running Windows XP. The target sends the UDP packets using sendto. The
client receives them using recvfrom.
If the update frequency is low, say 10Hz, there is no problem; the target
sends an 1880-byte datagram, which is received and processed by the Windows
client with no problem.
Once the update frequency goes to 15Hz, Windows occasionally receives a
burst of split datagrams; it'll receive a string of 1880-byte updates,
then receive a pair of short updates containing 1792 and 88 bytes. After
a string of five short updates, it's back to the 1880-byte datagrams for
a while. The 1792 and 88 byte pair appear to be an 1880-byte datagram
that has been split.
The frequency of the 1792/88 byte split increases as the update
frequency increases. At 60Hz, I'll receive a string of 11 split updates
before I start receiving 1880-byte updates for a while.
If I redirect the destination of the updates to localhost on the vxWorks
target, *every* datagram is split regardless of update frequency, but at
a different boundary; instead of a 1792/88 pair, I'll get a 1752/128
The target's sendto does not return an error; it always claims that it
has sent 1880 bytes.
The client's recvfrom also does not return an error; I get good status
on both the 1880 byte updates and the split pairs.
Anyone else seen something like this?
Re: Occasionally splitting large UDP datagrams?
Found it; when I created the socket, I trimmed the buffer sizes. Since
I wasn't going to receive on the socket, I didn't need any receive
buffering. For some reason, I also decided to trim the send buffer.
A bit too far, apparently. Embiggening the send buffer fixed the