RFC 3081 (rfc3081) - Page 2 of 8

Mapping the BEEP Core onto TCP

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