net: malformed payload of UDP packets on Mac #27084
Comments
cc @mikioh |
You need to deal with the number of bytes received appropriately like the following:
For more questions, please take a look at https://github.com/golang/go/wiki/Questions. |
@mikioh example clarification: Shouldn't that print come before the error check?
|
The net.UDPConn conforms to not only io.Reader interface but net.Conn and net.PacketConn interfaces. In addition, the net.UDPConn doesn't implement a few features that satisfy io.Reader interface such as returning io.EOF at the message, I mean, a unit of data exchange, boundary. Can we rely on io.Reader interface over net.UDPConn? That's a good question, though, I still have no concrete answer. It's probably okay w/ a few limitations such as io.EOF on almost all the existing implementations, but there will probably be exceptions, for example, on platforms enabling fancy LRO (large-receive-optimization) under heavy load, a microcode in some networking peripheral may advise that it perhaps returns an error with a corrupted number of bytes transferred because of the lack of spare logic-gates or machine cycles. |
Go version: go1.10.3 darwin/amd64
Does this issue reproduce with the latest release? Yes
OS and architecture: darwin/amd64 (OS High Sierra 10.13.3)
What did you do?
Listened to SIP communciation on UDP.
Code: https://play.golang.org/p/fqTQEMb70Is (naturally, needs to be run locally)
What did you expect to see?
Correct SIP Invite packet arriving every second, or so.
First 16 characters of a correct SIP Invite:
00000000 49 4e 56 49 54 45 20 73 69 70 3a 31 34 35 36 40 |INVITE sip:1456@|
What did you see instead?
First 4 character of some packets are malformed. Namely, the "INVI" was overwritten with two CRLF.
Initially, about 30% of the packets have the issue but the longer the server executes, the higher part of the whole they constitute. First 16 characters of a malformed packet:
00000000 0d 0a 0d 0a 54 45 20 73 69 70 3a 31 34 35 36 40 |....TE sip:1456@|
The text was updated successfully, but these errors were encountered: