Asynchronous Channels for the Blocks Extensible Exchange Protocol (BEEP)
RFC 5573
Document | Type |
RFC - Experimental
(June 2009; No errata)
Was draft-thomson-beep-async (individual in app area)
|
|
---|---|---|---|
Author | Martin Thomson | ||
Last updated | 2015-10-14 | ||
Stream | IETF | ||
Formats | plain text html pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 5573 (Experimental) | |
Action Holders |
(None)
|
||
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 or make network-based requests as a part of servicing the request. Thomson Experimental [Page 2]Show full document text