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