Mapping the BEEP Core onto TCP
Extracted elements (19)
Although TCP imposes flow control on a per-connection basis, when multiple channels are simultaneously in use on a BEEP session, BEEP must provide a mechanism to avoid starvation and deadlock; to achieve this, BEEP re-introduces window-based flow control with a sliding window per channel.
Large messages should be segmented into frames no larger than two-thirds of TCP's negotiated maximum segment size, frames for different channels should be sent round-robin, and a single consolidating SEQ frame may be sent when multiple frames arrive simultaneously — these guidelines balance performance and fairness.
Services based on BEEP must be designed so that simultaneous TCP OPENs cannot occur, because a simultaneous TCP OPEN would result in both peers believing they are the initiator and neither peer being able to start any channels.
Implementors should follow the flow control guidelines in RFC 1122 Section 4.2.2.16, which states that a receiver SHOULD NOT shrink the window; only the portions of RFC 1122 concerning flow control are applicable when mapping BEEP onto TCP.
Before sending a message, the sending BEEP peer must ensure that the size of the payload is within the window advertised by the receiving peer; if not, the peer may segment the message, delay sending, or signal the application.
During BEEP session establishment, if the listening peer cannot allocate at least 4096 octets for channel 0, it must return a negative reply instead of a greeting.
Each time a frame is received, a SEQ frame should be sent whenever the window size that will be advertised is at least one half of the buffer space available to the channel.
If a BEEP peer is asked to create a channel and cannot allocate at least 4096 octets for that channel, it must decline creation of the channel as specified in Section 2.3.1.2 of RFC 3080.
Implementations should support transport layer APIs that convey congestion information to allow determination of available bandwidth share and notification of changes in estimated path bandwidth.
SEQ frames for a channel must have higher priority than messages for that channel, and BEEP peers must advertise windows based on available buffer space to allow data to be read from the transport service as soon as available.
When a SEQ frame is received with an invalid or undeterminable channel number, acknowledgement number, or window size, the BEEP session must be terminated without generating a response, and it is recommended that a diagnostic entry be logged.
A BEEP session is established when a TCP connection is established between two peers: the peer issuing a passive TCP OPEN is the listener, and the peer issuing an active TCP OPEN is the initiator.
A BEEP session is terminated when either peer issues the TCP ABORT call, and the TCP connection is subsequently aborted.
Every payload octet sent in each direction on a channel has an associated sequence number; the sequence number space ranges from 0 to 4294967295 (2**32 - 1) and all arithmetic is performed modulo 2**32.
The SEQ frame carries three parameters: a channel number, an acknowledgement number indicating the next expected sequence number, and a window size indicating how many payload octets beginning at the acknowledgement number the sender is prepared to receive.
When a channel is created, the sequence number of the first payload octet of the first data frame is 0, and the initial window size for that channel is 4096 octets.
When both peers agree to release a BEEP session, the peer sending the 'ok' reply immediately issues the TCP CLOSE call, and upon receiving the reply, the other peer immediately issues the TCP CLOSE call.
Security considerations for BEEP over TCP are deferred to Section 9 of the BEEP Core specification (RFC 3080); this document introduces no additional security mechanisms.
A SEQ frame has the ABNF format: 'SEQ SP channel SP ackno SP window CR LF', where ackno is the next expected sequence number and window is the number of payload octets the sender is prepared to receive on that channel.