Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
net: document PacketConn IO operations in relation to packet sizes #18056
The current phrasing on
What is the expected behavior of
On the flip-side, what happens when the buffer provided to
It indeed depends on the underlying protocol and its implementation attaching to the PacketConn interface. Also the underlying protocol affects the behavior of IO operations not only for PacketConn but for Conn interface. We need to update the documentation on Conn interface too for a Conn created by Dial("udp", ...).
Almost all the implementations of connectionless datagram (e.g. UDP) or connection-oriented chunk protocols (e.g. SCTP or AF_UNIX+SOCK_SEQPACKET) allow only datagram (or chunk) basis IO calls. A read (or variant such as recv, recvfrom or recvmsg) system call waits for datagram arrival and copies the payload from the datagram as much as possible, and discards remaining portion by default when the supplied destination space is not enough large. A few platforms support an option which is able to retain the remaining portion until the next read call, but we probably don't need to state such optional behavior.
When the stack, say UDP over IP, supports datagram fragmentation and reassembly features, the stack takes care of it and the IP datagrams on the wire will be a series of fragmented ones. Otherwise a write (or variant such as send, sendto or sendmsg) system call may return an error. The transmission process of datagrams refers to various kernel states such as maximum datagram size for UDP and metrics like link and path MTU values, and the behavior of transmission buffer exhaustion is different between connectionless datagram protocols and connection-oriented chunk protocols. In general a write call may return various errors depend on the circumstances.
Calling UDPConn readers (Read, ReadFrom, ReadMsgUDP) to read part of datagram returns error (in Windows), mentioning there is more data available, and 0 as size of read data, even though part of data is already read. This fix makes UDPConn readers to return truncated payload size, even there is error due more data available to read. Fixes #14074 Updates #18056 Change-Id: Id7eec7f544dd759b2d970fa2561eef2937ec4662 Reviewed-on: https://go-review.googlesource.com/92475 Run-TryBot: Mikio Hara <email@example.com> TryBot-Result: Gobot Gobot <firstname.lastname@example.org> Reviewed-by: Mikio Hara <email@example.com>