RFC 3081 (rfc3081) - Page 2 of 8
Mapping the BEEP Core onto TCP
Alternative Format: Original Text Document
RFC 3081 Mapping the BEEP Core onto TCP March 2001
2. Session Management
The mapping of BEEP session management onto the TCP service is
straight-forward.
A BEEP session is established when a TCP connection is established
between two BEEP peers:
o the BEEP peer that issues a passive TCP OPEN call is termed the
listener; and,
o the BEEP peer that issues an active TCP OPEN call is termed the
initiator.
A simultaneous TCP OPEN would result in both BEEP peers believing
they are the initiator and neither peer will be able to start any
channels. Because of this, services based on BEEP must be designed
so that simultaneous TCP OPENs cannot occur.
If both peers agree to release a BEEP session (c.f., [1]'s Section
2.4), the peer sending the "ok" reply, immediately issues the TCP
CLOSE call. Upon receiving the reply, the other peer immediately
issues the TCP CLOSE call.
A BEEP session is terminated when either peer issues the TCP ABORT
call, and the TCP connection is subsequently aborted.
3. Message Exchange
The mapping of BEEP exchanges onto the TCP service is less straight-
forward.
Messages are reliably sent and received using TCP's SEND and RECEIVE
calls. (This also provides ordered delivery of messages on the same
channel.)
Although TCP imposes flow control on a per-connection basis, if
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 a mechanism used by the TCP:
window-based flow control -- each channel has a sliding window that
indicates the number of payload octets that a peer may transmit
before receiving further permission.
Rose Standards Track