Portal control messages use discv5 TALK. Content that does not fit in one UDP response uses uTP packets carried in discv5 TALK requests.
Wire surface
The TALK protocol byte string is utp (0x757470). Every uTP packet goes in a
TALKREQ. uTP ignores the matching TALKRESP.
Portal sends the two-byte uTP connection ID out of band in Content or
Accept. A connection key includes IP, UDP port, discv5 node ID, and connection
ID. This prevents two authenticated discovery peers from colliding on the same
UDP tuple.
Content framing
Each content item starts with an unsigned LEB128 length up to uint32. A
FindContent stream carries one item. An accepted offer stream carries at most
64 accepted items in offer order, each with its own length.
The uTP state machine follows BEP 29 with the pinned Portal changes. It uses
discv5 instead of raw UDP, allows ST_DATA before the initiator's first data
packet after the authenticated handshake, and follows the reference
implementation's SYN acknowledgement number (ack_nr = pkt.seq_nr - 1).
Failure handling
Malformed or truncated length framing and invalid uTP sequence state make the transfer unusable; the receiver must not store the item. BEP 29 supplies retransmission, acknowledgement, timeout, and congestion-control behavior for loss. Implementations apply local limits to open connections and offered bytes per peer.
Design rationale
discv5 protects the peer address and session. uTP adds ordered, congestion-aware transfer for content larger than a discovery datagram.
Status and open points
The pinned uTP document does not resolve whether a TALKRESP is required for
each uTP TALKREQ. uTP packets must not be sent in TALKRESP; an implementation
may send a response to satisfy a discv5 peer, and the uTP layer must ignore that
response. This point remains open in the checked-in protocol.