Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)
RFC 5573

• Document
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

Document	Type		RFC - Experimental (June 2009; No errata) Was draft-thomson-beep-async (individual in app area)
	Last updated		2015-10-14
	Stream		IETF
	Formats		plain text pdf html bibtex
Stream	WG state		(None)
	Document shepherd		No shepherd assigned
IESG	IESG state		RFC 5573 (Experimental)
	Consensus Boilerplate		Unknown
	Telechat date
	Responsible AD		Alexey Melnikov
	Send notices to		(None)

Network Working Group                                         M. Thomson
Request for Comments: 5573                                        Andrew
Category: Experimental                                         June 2009

Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)

Status of This Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   The Blocks Extensible Exchange Protocol (BEEP) provides a protocol
   framework for the development of application protocols.  This
   document describes a BEEP feature that enables asynchrony for
   individual channels.

Table of Contents

   1. Introduction ....................................................2
   2. Asynchronous BEEP Channels ......................................3
      2.1. Asynchronous Feature .......................................3
      2.2. Starting an Asynchronous Channel ...........................4
      2.3. Asynchronous Channel Behavior ..............................5
      2.4. Error Handling .............................................6
   3. Alternatives ....................................................6
      3.1. Increasing Throughput ......................................6
      3.2. Asynchrony in the Application Protocol .....................7
   4. Security Considerations .........................................7
   5. IANA Considerations .............................................8
   6. References ......................................................8
      6.1. Normative References .......................................8
      6.2. Informative References .....................................8

Thomson                       Experimental                      [Page 1]
RFC 5573               Asynchronous BEEP Channels              June 2009

1.  Introduction

   The Blocks Extensible Exchange Protocol (BEEP) provides a protocol
   framework that manages many of the aspects necessary in developing an
   application protocol: framing, encoding, privacy, authentication, and
   asynchrony.  However, the asynchrony provided by BEEP is limited to
   asynchrony between channels; replies to messages sent on any channel
   are strictly ordered.

   Serial processing behavior is desirable for a range of applications.
   However, serial processing is less suitable for applications that
   rely more heavily on asynchrony.  In particular, if a response takes
   a significant amount of time to create, the channel is effectively
   blocked until the request has been processed and the response sent.
   Pipelining only ensures that network latency does not add to this
   time; subsequent requests cannot be processed until a response is
   made to the first request.

   Asynchronous applications require a protocol that is able to support
   a large number of concurrent outstanding requests.  The analogy of a
   channel as a thread does not scale to the large number of threads
   used in modern systems.  Modern applications regularly have large
   numbers of concurrent processing threads.  Thus, a better way of
   multiplexing large numbers of concurrent requests is required.

   This document describes a BEEP feature, an extension to BEEP, that
   enables the creation of an asynchronous channel.  An asynchronous
   channel is a channel where response ordering is not fixed to the
   order of the requests sent by the client peer.  An asynchronous
   channel is identical to other channels, using unmodified framing;
   except that requests may be processed in parallel and responses may
   be sent in any order.

   An asynchronous channel enables the efficient use of a single channel
   for multiple concurrent requests.  There is no impact on requests
   arising from the timing of responses to other requests.  The
   requesting peer can process responses to the requests it sends as
   they come available; similarly, the serving peer can take advantage
   of parallel processing without artificial constraints on the order of
   responses.

   Asynchronous channels allow for greater throughput where the serving
   peer requires any time to process requests.  This is particularly
   relevant where the serving peer needs to perform lengthy computations

Show full document text