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.