Length byte overflows for some messages

[jason-watkins]

Summary

Some messages are longer than 255 bytes, causing the length field in the GETD command to overflow.

Description

When requesting several DREFs with the GETD command, it is relatively easy to create a message which is longer than 255 bytes. This currently produces inconsistent behavior depending on which client is used. The Java client throws an exception without attempting to send the command, while the C and MATLAB clients send the command with an undefined value in the length field.

The plugin currently draws length information primarily from the return value of the recvfrom function. At least in the case of the GETD command, the length field seems to be entirely ignored. As a result, the plugin deals with these long messages without issue.

This may present a problem if the plugin ever receives a partial message or multiple messages squashed together. The former is relatively easy to fix, but the latter would be problematic.

Proposed Solution

If someone can provide information indicating that recvfrom will never return multiple UDP datagrams in a single call, then we can simply remove the length check from the Java client and explicitly ignore the length field in the future. In this case, partial datagrams will be seen as invalid during the parsing phase and discarded.

Otherwise, the length field needs to be expanded to 2 bytes, raising the max message length from 255 to 65535. This should be more than enough room for any command.

[jason-watkins]

It looks like recvfrom always returns either a complete datagram or nothing. It isn't possible to receive either a partial datagram or multiple datagrams. Therefore, we can use the length reported by recvfrom as the definitive packet length and ignore the length byte in the packet itself. We will leave the byte in there for compatability, but its value should now be considered indeterminate and ignored.