DOCSLIB.ORG

You're Writing a Networked Application, and You Want Instances of Your

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
You're Writing a Networked Application, and You Want Instances of Your Rheinisch-Westfälische Technische Hochschule Aachen Lehrstuhl für Informatik IV Prof. Dr. rer. nat. Otto Spaniol Blocks Extensible Exchange Protocol (BEEP) Seminar: Datenkommunikation und verteilte Systeme Wintersemster 2003/2004 Sandra Cüsters Matrikelnummer: 223195 Betreuung: Torsten Dinsing Ericsson Eurolab Deutschland GmbH, Herzogenrath 1 1. Introduction........................................................................................................... 3 2. The Design of Application Protocols..................................................................... 4 2.1 Protocol Mechanisms ..................................................................................... 4 2.2 Protocol Properties ......................................................................................... 4 2.3 Pipelining ........................................................................................................ 5 3. BEEP.................................................................................................................... 6 3.1 BEEP Concepts.............................................................................................. 7 3.1.1 BEEP Sessions..................................................................................... 7 3.1.2 Types of Interaction .............................................................................. 8 3.1.3 Framing of Messages ........................................................................... 8 3.1.4 Message Semantics............................................................................ 10 3.2 Asynchrony................................................................................................... 12 3.3 Transport Mappings...................................................................................... 12 4. Mapping BEEP onto TCP ................................................................................... 13 4.1 Message Exchange ...................................................................................... 13 4.2 Flow Control ................................................................................................. 13 5. BEEP Profiles ..................................................................................................... 15 6. Simple Object Access Protocol (SOAP) ............................................................. 16 6.1 Using SOAP in BEEP ................................................................................... 16 6.1.1 SOAP BEEP Example ........................................................................ 17 6.2 Using SOAP in HTTP ................................................................................... 18 6.2.1 SOAP HTTP Request ......................................................................... 18 6.2.2 SOAP HTTP Response....................................................................... 18 6.2.3 SOAP HTTP Examples....................................................................... 19 7. Comparison between BEEP and HTTP.............................................................. 20 7.1 Asynchronous Notification ............................................................................ 20 7.2 Multiple Requests ......................................................................................... 20 7.2.1 Features of HTTP/1.1 by Contrast with BEEP .................................... 21 8. Summary ............................................................................................................ 22 9. Literature ............................................................................................................ 23 10. Abbreviations...................................................................................................... 24 2 1. Introduction Within networked applications instances of the programs should be able to communicate via transport protocols (e.g. TCP/IP). Before getting around to the logic of the applications itself, it is to be defined how the programs are going to connect, authenticate themselves, send messages and report errors. The cumulative time spending on this may well outweigh the effort needed for the application logic itself. This is the problem BEEP (Blocks Extensible Exchange Protocol) tries to solve. It implements all the “hygiene factors” of creating a new network protocol. But why do we need another type of distributed computing protocol to add to CORBA, SOAP or XML-RPC. The answer is: BEEP sits at a different level. It is a generic application protocol framework. For example SOAP is a protocol for accessing a Web Service and can easily be implemented on top of BEEP. BEEP takes care of the connections, the authentication and the packaging up at the TCP/IP level of the messages. BEEP really competes on the same level as HTTP. SOAP CORBA XML.RPC ........ HTTP BEEP SMTP FTP ...... TCP/UDP Figure 1: three different layers At first an overview on the design of application protocols, their mechanisms and properties will be given. This work will then introduce the BEEP framework and its mapping for TCP. Taking the example of SOAP, it will be illustrated how SOAP can be bound to HTTP on the one hand and to BEEP and on the other hand. The work will finally compare these two scenarios. 3 2. The Design of Application Protocols In 1998, one of the most prolific creators of internet protocols, Dr. Marshall T. Rose, realized that the design of new internet protocols had reached a critical point. Marshall Rose teamed up with Carl Malamud to invent a new application protocol. Creating an application protocol, there are four possible ways to proceed: S find an existing exchange protocol that (more or less) does what you want; S define an exchange model on top of the world-wide web infrastructure that (more or less) does what you want; S define an exchange model on top of the electronic mail infrastructure that (more or less) does what you want; or, S define a new protocol from scratch that does exactly what you want. The most appealing option is to find an existing protocol and use that. So, M. Rose and C. Malamud did a survey of many existing application protocols and found that none of them were a good match for the semantics of the protocol they needed. They decided to define a new protocol called BEEP from scratch. 2.1 Protocol Mechanisms After selecting one of the four possible ways, the next step is to look at the tasks that an application protocol must perform and how it works. The most impotent items within such an application protocol are: S framing, which tells how the beginning and ending of each message is delimited; S encoding, which tells how a message is represented when exchanged; S reporting, which tells how errors are described; S asynchrony, which tells how the exchanges are handled; S authentication, which tells how the peers at each end of the connection are identified and verified against third-party interception or modification 2.2 Protocol Properties Designing an application protocol, there are a few properties one should keep an eye on. S Scalability: Because few application protocols support asynchrony, a common trick is for a program to open multiple simultaneous connections to a single destination. In theory this reduces latency and increases throughput. In reality the 4 transport layer as well as the server are viewing each connection as an independent instance of the application protocol, and this can cause problems. Another important aspect of scalability to consider is the relative numbers of clients and servers. Typically, there are many more client peers than server peers. In this case functional requirements should be shifted from the servers to the clients. S Efficiency: For example, although octet-stuffing leads to more elegant implementations, it should be replaced though octet-counting. Experiences show that octet-counting consumes far fewer cycles. But recognise that you sometimes have to compromise efficiency in order to satisfy other properties. S Simplicity: A well-designed protocol should be as simple as possible. Simple does not mean simple-minded. Something well designed focused all problems, even the smallest problems, in a domain. Doing this in a consistent fashion makes the design simple. Typically, this leads to an elegant design. S Extensibility: The protocol should be evolutionary, and there must be a way for implementations reflecting different steps in the evolutionary path to negotiate which extension will be used. S Robustness: Robustness and efficiency are often at odds. For example, although defaults are useful to reduce packet sizes and processing time, they tend to encourage implementation errors. 2.3 Pipelining Few application protocols today allow independent exchanges over the same connection. In fact, the more widely implemented approach is to allow pipelining. With pipelining a client can make multiple requests to a server within a single connection, but requires the requests to be processed serially. It is a powerful method for reducing network latency. In addition to reducing network latency, asynchrony also reduces server latency by allowing multiple requests to be processed by multi-threaded implementations. Using this kind of parallelism, a flow control mechanisms is needed to avoid starvation and deadlocks. Flow control is typically implemented at the transport layer. For example, TCP uses sequence numbers and a sliding window. Using flow control a segmentation mechanism is needed to fragment messages into smaller pieces before sending and
Load more

Recommended publications
  • Implementing the Intrusion Detection Exchange Protocol
    Implementing the Intrusion Detection Exchange Protocol Tim Buchheim, Michael Erlinger, Ben Feinstein, Harvey Mudd College, Harvey Mudd College, Guardent, Inc. [email protected], [email protected], [email protected] Greg Matthews,∗ Roy Pollock, Harvey Mudd College, Harvey Mudd College [email protected], [email protected] Joseph Betser, Andy Walther The Aerospace Corporation, The Aerospace Corporation [email protected], [email protected] † Abstract We describe the goals of the IETF’s Intrusion Detection Working Group (IDWG) and the requirements for a trans- port protocol to communicate among intrusion detection systems. We then describe the design and implementation of IAP, the first attempt at such a protocol. After a discussion of IAP’s limitations, we discuss BEEP, a new IETF general framework for application protocols. We then describe the Intrusion Detection Exchange Protocol (IDXP), a transport protocol designed and implemented within the BEEP framework that fulfills the IDWG requirements for its transport protocol. We conclude by discussing probable future directions for this ongoing effort. 1 Introduction 2 The IETF-IDWG 2.1 IETF Intrusion detection is an area of increasing concern in the Internet community. In response to this, many The IETF is the engineering, development and stan- automated intrusion detection systems have been devel- dardization arm of the Internet Architecture Board oped. However, there is no standardized way for them (IAB). The IETF is where the Internet protocol speci- to communicate. To remedy this, the Intrusion Detec- fications are developed. tion Working Group was chartered under the auspices of The IETF’s mission includes: the Internet Engineering Task Force.
    [Show full text]
  • 4643 Cornell University Updates: 2980 K
    Network Working Group J. Vinocur Request for Comments: 4643 Cornell University Updates: 2980 K. Murchison Category: Standards Track Carnegie Mellon University October 2006 Network News Transfer Protocol (NNTP) Extension for Authentication Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines an extension to the Network News Transfer Protocol (NNTP) that allows a client to indicate an authentication mechanism to the server, to perform an authentication protocol exchange, and optionally to negotiate a security layer for subsequent protocol interactions during the remainder of an NNTP session. This document updates and formalizes the AUTHINFO USER/PASS authentication method specified in RFC 2980 and deprecates the AUTHINFO SIMPLE and AUTHINFO GENERIC authentication methods. Additionally, this document defines a profile of the Simple Authentication and Security Layer (SASL) for NNTP. Vinocur, et al. Standards Track [Page 1] RFC 4643 NNTP Authentication October 2006 Table of Contents 1. Introduction ............................................. 3 1.1. Conventions Used in This Document ................... 3 2. The AUTHINFO Extension ................................... 4 2.1. Advertising the AUTHINFO Extension .................. 4 2.2. Authenticating with the AUTHINFO Extension .......... 5 2.3. AUTHINFO USER/PASS Command .......................... 6 2.3.1. Usage ........................................ 7 2.3.2. Description .................................. 7 2.3.3. Examples ..................................... 9 2.4. AUTHINFO SASL Command ............................... 9 2.4.1. Usage .......................................
    [Show full text]
  • Simple Authentication and Security Layer - SASL CCERT-PUBDOC-2005-06-125
    Simple Authentication and Security Layer - SASL CCERT-PUBDOC-2005-06-125 Sigurnosni problemi u računalnim programima i operativnim sustavima područje je na kojem CARNet CERT kontinuirano radi. Rezultat toga rada ovaj je dokument, koji je nastao suradnjom CARNet CERT-a i LS&S-a, a za koji se nadamo se da će Vam koristiti u poboljšanju sigurnosti Vašeg sustava. CARNet CERT, www.cert.hr - nacionalno središte za sigurnost računalnih mreža i sustava. LS&S, www.lss.hr - laboratorij za sustave i signale pri Zavodu za elektroničke sustave i obradbu informacija Fakulteta elektrotehnike i računarstva Sveučilišta u Zagrebu. Ovaj dokument predstavlja vlasništvo CARNet-a (CARNet CERT-a). Namijenjen je za javnu objavu, njime se može svatko koristiti, na njega se pozivati, ali samo u originalnom obliku, bez ikakvih izmjena, uz obavezno navođenje izvora podataka. Korištenje ovog dokumenta protivno gornjim navodima, povreda je autorskih prava CARNet-a, sukladno Zakonu o autorskim pravima. Počinitelj takve aktivnosti podliježe kaznenoj odgovornosti koja je regulirana Kaznenim zakonom RH. Revizija v1.1 CCERT-PUBDOC-2005-06-125 Stranica 2 / 13 Sadržaj 1. UVOD..................................................................................................................................................4 2. SASL – SIMPLE AUTHENTICATION AND SECURITY LAYER ............................................................................5 2.1. KONCEPT IDENTITETA..............................................................................................................................
    [Show full text]
  • The Blocks Extensible Exchange Protocol Core, RFC 3080
    Network Working Group M. Rose Request For Comments: 3080 Invisible Worlds, Inc. Category: Standards Track March 2001 The Blocks Extensible Exchange Protocol Core Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract This memo describes a generic application protocol kernel for connection-oriented, asynchronous interactions called the BEEP (Blocks Extensible Exchange Protocol) core. BEEP permits simultaneous and independent exchanges within the context of a single application user-identity, supporting both textual and binary messages. Rose Standards Track [Page 1] RFC 3080 The BEEP Core March 2001 Table of Contents 1. Introduction . 4 2. The BEEP Core . 5 2.1 Roles . 6 2.1.1 Exchange Styles . 6 2.2 Messages and Frames . 7 2.2.1 Frame Syntax . 8 2.2.1.1 Frame Header . 9 2.2.1.2 Frame Payload . 12 2.2.1.3 Frame Trailer . 13 2.2.2 Frame Semantics . 14 2.2.2.1 Poorly-formed Messages . 14 2.3 Channel Management . 15 2.3.1 Message Semantics . 16 2.3.1.1 The Greeting Message . 16 2.3.1.2 The Start Message . 17 2.3.1.3 The Close Message . 20 2.3.1.4 The OK Message . 23 2.3.1.5 The Error Message . 23 2.4 Session Establishment and Release .
    [Show full text]
  • Number 2, June 2002
    June 2002 Volume 5, Number 2 A Quarterly Technical Publication for From The Editor Internet and Intranet Professionals In This Issue The networking industry is full of acronyms, as the table of contents for this issue clearly illustrates. According to the dictionary, an acronym is “...a word formed from the initial letter or letters of each of the succes- From the Editor .......................1 sive parts or major parts of a compound term.” While neither BEEP nor ENUM are strictly speaking acronyms, these “short names” are becom- BEEP........................................2 ing ever more prevalent and difficult to keep track of. We promise to continue to provide acronym expansion whenever possible. ENUM...................................13 BEEP is an example of a technology that came to life in a very short time. While IETF standards often take years from initial idea to proto- DHCP ....................................24 col specification, BEEP seems to have happened in just over a year. There is already a textbook on BEEP from which our first article is adapted. Marshall Rose gives an overview of the BEEP framework and Book Review..........................32 explains how you can get involved in its further development. ENUM refers to the use of the Domain Name System (DNS) to look up Call for Papers .......................35 telephone numbers and subsequently route telephone calls to the right destination using the Internet as the underlying routing fabric. This inte- Fragments ..............................36 gration of the traditional telephone network with the Internet is becoming a reality and several standardization bodies are working on technologies to make this as seamless as possible. Geoff Huston ex- plains the mechanisms and politics behind ENUM.
    [Show full text]