[erlang-bugs] gen_udp behaviour

[Bengt Kleberg]

Greetings,

I would suggest that gen_udp only sends the number of bytes specified in
the UDP packet header.

If backwards compatibility mandates that the current behaviour is
maintained for existing applications, then a flag could turn on the new
(correct) behaviour. Add to open/2 options something like this:
{receive_correct_length, true}


bengt

On Tue, 2009-12-29 at 02:13 -0600, Steve Davis wrote:
> Frankly, I'm not clear on what the solution to the following situation 
> should be from the OTP side, *if any*, but I thought I should at least 
> report this edge-case behaviour.
> 
> I'm communicating with a badly behaved UDP server that is unpredictably 
> appending additional bytes to sent udp packets beyond the declared 
> payload length.
> 
> Example capture from WireShark:
> ---
> Frame 1203 (60 bytes on wire, 60 bytes captured)
> User Datagram Protocol, Src Port: 12035 (12035), Dst Port: oc-lm (1448)
>      Source port: 12035 (12035)
>      Destination port: oc-lm (1448)
>      Length: 23
>      Checksum: 0xb2a0 [correct]
> Data (15 bytes)
>      Data: 000000000100FFFFFFFB0101000000
> 
> 0000  00 c0 9f 7f 26 c2 00 c0 49 db ac d0 08 00 45 00   ....&...I.....E.
> 0010  00 2b 00 00 40 00 38 11 2c 4b d8 52 02 16 c0 a8   .+..@REDACTED,K.R....
> 0020  7b 66 2f 03 05 a8 00 17 b2 a0 00 00 00 00 01 00   {f/.............
> 0030  ff ff ff fb 01 01 00 00 00 00 00 00               ............
> ---
> 
> As you can see, the actual payload length is correctly set for the 
> message, but the server has chosen (in this case) to append three 
> additional zero bytes.
> 
> Rather than just the 15 bytes of data, gen_udp is returning the data 
> plus the erroneous extra bytes - i.e. a total of 18 bytes that were 
> actually sent over the wire.
> 
> The reason this has caused me a development issue is that without 
> knowing the length specified in the UDP packet header it's makes it 
> tough to parse some messages from this incorrectly-implemented server 
> reliably.
> 
> What the solution to this should be -- I'm not entirely sure.
> 
> Regards,
> Steve
> 
> 
> ________________________________________________________________
> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> erlang-bugs (at) erlang.org
>