1332065 - NSPR fragments UDP packets by default without reassembling them

Status: NEW

(NSPR :: NSPR, defect)

Description

[Nils Ohlmeier [:drno]]

On Windows NSPR when sending a UDP packet out by default (that is if the non-blocking option is not set) splits the payload over several UDP packets in this loop here: http://searchfox.org/mozilla-central/rev/790b2cb423ea1ecb5746722d51633caec9bab95a/nsprpub/pr/src/io/prsocket.c#754

Same thing happens one layer further down again: http://searchfox.org/mozilla-central/rev/790b2cb423ea1ecb5746722d51633caec9bab95a/nsprpub/pr/src/md/windows/w95sock.c#297

This is bad because:
- the caller of PR_SendTo does not get notified if the bytes have been send in one or more packets
- if the packet get send to destination in multiple packets, but 
  - the first packet, which for UDP usually carries some form of header, get lots the receiver has no idea what to do with the subsequent packets without the missing header from the first packet
  - if packets arrive out of order the receiver has way to figure out in which order it needs to re-assemble the packets to get the expected payload

If sending of the requested amount of bytes did not succeed (less bytes got written into the ONE UDP packet) the application logic needs to be notified of this so it can figure out if and how it can or want to recover from this problem. NSPR should not try to cover up this problem, which the receiver can possibly not recover from (see above).

BTW the pthread implementation for Unix does not try to any of this, but just send the data in one packet as expected: http://searchfox.org/mozilla-central/rev/790b2cb423ea1ecb5746722d51633caec9bab95a/nsprpub/pr/src/pthreads/ptio.c#2017