As per Relevance of the word sequence, we have this rfc below:
Network Working Group M.
Request for Comments: 3081 Invisible Worlds, Inc
Category: Standards Track March 2001
Mapping the BEEP Core onto
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This memo describes how a BEEP (Blocks Extensible Exchange Protocol
session is mapped onto a single TCP (Transmission Control Protocol
connection
Table of
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
2. Session Management . . . . . . . . . . . . . . . . . . . . . 2
3. Message Exchange . . . . . . . . . . . . . . . . . . . . . . 2
3.1 Flow Control . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1.1 Channel Creation . . . . . . . . . . . . . . . . . . . . . . 3
3.1.2 Sending Messages . . . . . . . . . . . . . . . . . . . . . . 3
3.1.3 Processing SEQ Frames . . . . . . . . . . . . . . . . . . . 4
3.1.4 Use of Flow Control . . . . . . . . . . . . . . . . . . . . 4
4. Security Considerations . . . . . . . . . . . . . . . . . . 6
References . . . . . . . . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . 6
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
Full Copyright Statement . . . . . . . . . . . . . . . . . . 8
1.
This memo describes how a BEEP [1] session is mapped onto a
TCP [2] connection. Refer to Section 2.5 of [1] for an
of the mapping requirements
Rose Standards Track [Page 1]
RFC 3081 Mapping the BEEP Core onto TCP March 2001
2. Session
The mapping of BEEP session management onto the TCP service
straight-forward
A BEEP session is established when a TCP connection is
between two BEEP peers
o the BEEP peer that issues a passive TCP OPEN call is termed
listener; and
o the BEEP peer that issues an active TCP OPEN call is termed
initiator
A simultaneous TCP OPEN would result in both BEEP peers
they are the initiator and neither peer will be able to start
channels. Because of this, services based on BEEP must be
so that simultaneous TCP OPENs cannot occur
If both peers agree to release a BEEP session (c.f., [1]'s
2.4), the peer sending the "ok" reply, immediately issues the
CLOSE call. Upon receiving the reply, the other peer
issues the TCP CLOSE call
A BEEP session is terminated when either peer issues the TCP
call, and the TCP connection is subsequently aborted
3. Message
The mapping of BEEP exchanges onto the TCP service is less straight
forward
Messages are reliably sent and received using TCP's SEND and
calls. (This also provides ordered delivery of messages on the
channel.)
Although TCP imposes flow control on a per-connection basis,
multiple channels are simultaneously in use on a BEEP session,
must provide a mechanism to avoid starvation and deadlock.
achieve this, BEEP re-introduces a mechanism used by the TCP
window-based flow control -- each channel has a sliding window
indicates the number of payload octets that a peer may
before receiving further permission
Rose Standards Track [Page 2]
RFC 3081 Mapping the BEEP Core onto TCP March 2001
3.1 Flow
Recall from Section 2.2.1.2 of [1] that every payload octet sent
each direction on a channel has an associated sequence number
Numbering of payload octets within a data frame is such that
first payload octet is the lowest numbered, and the following
octets are numbered consecutively
The actual sequence number space is finite, though very large
ranging from 0..4294967295 (2**32 - 1). Since the space is finite
all arithmetic dealing with sequence numbers is performed
2**32. This unsigned arithmetic preserves the relationship
sequence numbers as they cycle from 2**32 - 1 to 0 again.
Sections 2 through 5 of [3] for a discussion of the
properties of sequence numbers
3.1.1 Channel
When a channel is created, the sequence number associated with
first payload octet of the first data frame is 0, and the
window size for that channel is 4096 octets. After channel creation
a BEEP peer may update the window size by sending a SEQ
(Section 3.1.3).
If a BEEP peer is asked to create a channel and it is unable
allocate at least 4096 octets for that channel, it must
creation of the channel, as specified in Section 2.3.1.2 of [1].
Similarly, during establishment of the BEEP session, if the BEEP
acting in the listening role is unable to allocate at least 4096
octets for channel 0, then it must return a negative reply,
specified in Section 2.4 of [1], instead of a greeting
3.1.2 Sending
Before a message is sent, the sending BEEP peer must ensure that
size of the payload is within the window advertised by the
BEEP peer. If not, it has three choices
o if the window would allow for at least one payload octet to
sent, the BEEP peer may segment the message and start by sending
smaller data frame (up to the size of the remaining window);
o the BEEP peer may delay sending the message until the
becomes larger; or
Rose Standards Track [Page 3]
RFC 3081 Mapping the BEEP Core onto TCP March 2001
o the BEEP peer may signal to its application that it is unable
send the message, allowing the application to try again at a
time (or perhaps signaling its application when a larger window
available).
The choice is implementation-dependent, although it is
that the application using BEEP be given a mechanism for
the decision
3.1.3 Processing SEQ
As an application accepts responsibility for incoming data frames
its BEEP peer should send SEQ frames to advertise a new window
The ABNF [4] for a SEQ frame is
seq = "SEQ" SP channel SP ackno SP window CR
ackno =
window =
; channel, seqno, and size are defined in Section 2.2.1 of [1].
The SEQ frame has three parameters
o a channel number
o an acknowledgement number, that indicates the value of the
sequence number that the sender is expecting to receive on
channel; and
o a window size, that indicates the number of payload
beginning with the one indicated by the acknowledgement
that the sender is expecting to receive on this channel
A single space character (decimal code 32, " ") separates
component. The SEQ frame is terminated with a CRLF pair
When a SEQ frame is received, if any of the channel number
acknowledgement number, or window size cannot be determined or
invalid, then the BEEP session is terminated without generating
response, and it is recommended that a diagnostic entry be logged
3.1.4 Use of Flow
The key to successful use of flow control within BEEP is to
performance and fairness
Rose Standards Track [Page 4]
RFC 3081 Mapping the BEEP Core onto TCP March 2001
o large messages should be segmented into frames no larger
two-thirds of TCP's negotiated maximum segment size
o frames for different channels with traffic ready to send should
sent in a round-robin fashion
o each time a frame is received, a SEQ frame should be sent
the window size that will be sent is at least one half of
buffer space available to this channel; and
o if the transport service presents multiple frames to a BEEP
simultaneously, then a single consolidating SEQ frame may be sent
In order to avoid pathological interactions with the
service, it is important that a BEEP peer advertise windows based
available buffer space, to allow data to be read from the
service as soon as available. Further, SEQ frames for a channel
have higher priority than messages for that channel
Implementations may wish to provide queue management facilities
the application using BEEP, e.g., channel priorities, (relative
buffer allocations, and so on. In particular, implementations
not allow a given channel to monopolize the underlying
window (e.g., slow readers should get small windows).
In addition, where possible, implementations should support
layer APIs that convey congestion information. These APIs allow
implementation to determine its share of the available bandwidth,
also be notified of changes in the estimated path bandwidth.
that when a BEEP session has multiple channels that
simultaneously exchanging large messages, implementations
access to this information may have uncertain fairness and
properties during times of network congestion
Finally, implementors should follow the guidelines given in
relevant portions of RFC1122 [5] that deal with flow control (
bear in mind that issues such as retransmission, while they
with flow control in TCP, are not applicable to this memo).
example, Section 4.2.2.16 of RFC1122 [5] indicates that a "
SHOULD NOT shrink the window, i.e., move the right window edge to
left" and then discusses the impact of this rule on
data. In the context of mapping BEEP onto a single TCP connection
only the portions concerning flow control should be implemented
Rose Standards Track [Page 5]
RFC 3081 Mapping the BEEP Core onto TCP March 2001
4. Security
Consult Section [1]'s Section 9 for a discussion of security issues
[1] Rose, M., "The Blocks Extensible Exchange Protocol Core",
3080, March 2001.
[2] Postel, J., "Transmission Control Protocol", STD 7, RFC 793,
September 1981.
[3] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996.
[4] Crocker, D. and P. Overell, "Augmented BNF for
Specifications: ABNF", RFC 2234, November 1997.
[5] Braden, R., "Requirements for Internet Hosts --
Layers", STD 3, RFC 1122, October 1989.
Author's
Marshall T.
Invisible Worlds, Inc
1179 North McDowell
Petaluma, CA 94954-6559
Phone: +1 707 789 3700
EMail: mrose@invisible.
URI: http://invisible.net
Rose Standards Track [Page 6]
RFC 3081 Mapping the BEEP Core onto TCP March 2001
Appendix A.
The author gratefully acknowledges the contributions of:
Crocker, Steve Harris, Eliot Lear, Keith McCloghrie, Craig Partridge
Vernon Schryver, and, Joe Touch. In particular, Dave
provided helpful suggestions on the nature of flow control in
mapping
Rose Standards Track [Page 7]
RFC 3081 Mapping the BEEP Core onto TCP March 2001
Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Rose Standards Track [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
