1.1 Connectionless versus Connection-Oriented Protocols

I l @ ve RuBoard

A protocol is a set of rules that specify how control and data information is exchanged between communicating entities, such as application processes interacting within a networked computing environment. Protocols can be generally classified as connectionless or connection-oriented. The primary trade-offs in this dimension involve latency, scalability, and reliability.

Connectionless protocols provide a message-oriented service in which each message can be routed and delivered independently. Connectionless protocols often use "best-effort" delivery semantics. These semantics don't guarantee that a series of messages will arrive in a particular order at their destination, or even that they'll ever arrive at all!

Widely used examples of connectionless protocols are the User Datagram Protocol (UDP) and Internet Protocol (IP). These protocols can be used directly by multimedia applications, such as voice-over-IP or streaming video [MSKS00], that can tolerate some degree of data loss. UDP/IP also supports unreliable multicast [DC90] and broadcast capabilities that enable a sender to communicate with a group of receivers.

Connection-oriented protocols provide a reliable, sequenced , nonduplicated delivery service, which is useful for applications that can't tolerate data loss. To enhance performance and ensure reliability, connection-oriented protocols exchange and maintain state information at the sender and/or receiver(s). The Transmission Control Protocol (TCP) is a connection-oriented protocol used in many session-oriented Internet applications, such as Web services and e-mail.

When connection-oriented protocols are used, application and middleware developers must also select from the following design alternatives:

• Data framing strategies. Connection-oriented protocols offer different types of data framing strategies. For example, message-oriented delivery strategies are supported by certain connection-oriented protocols, such as TP4 and XTP. In contrast, TCP is a bytestream protocol that doesn't preserve application message boundaries. Thus, if an application makes four send () calls to transmit four distinct messages over TCP, there will be one or more (and possibly greater than 4) TCP segments transmitted to the receiver. If an application requires message-oriented delivery therefore, the sender and receiver must perform extra processing to frame the four messages exchanged via TCP. If messages are always equal lengths and network errors never occur, framing is relatively simple; otherwise , it can be a nontrivial problem.

• Connection multiplexing strategies. The two general strategies for transmitting data over a connection-oriented protocol are shown in Figure 1.1 and described below:

  1. Multiplexed, wherein all client requests emanating from threads in a single process pass through one TCP connection to a server process, as shown in Figure 1.1 (1). An advantage of connection multiplexing is that it conserves OS communication resources, such as socket handles and connection control blocks. The disadvantages of this strategy are that it's harder to program [AOS ⁺ 00], less efficient [CB01], and less deterministic [SMFGG01]. These problems stem from the synchronization and context switching mechanisms required to associate requests with responses over a multiplexed connection.

  2. Nonmultiplexed, wherein each client uses a different connection to communicate with a peer service, as shown in Figure 1.1 (2). The primary advantage of nonmultiplexed connections is finer control of communication priorities. In the nonmultiplexed connection design, each connection's priority can be set individually, so that high-priority communication will be transmitted quickly, even if there's a large volume of low-priority communications traffic between other threads. This design avoids priority inversion , wherein low-priority threads monopolize a single multiplexed connection. In addition, since connections aren't shared, this strategy incurs low synchronization overhead because additional locks aren't needed to send and receive two-way requests. Compared with multiplexed connection strategies, non-multiplexed strategies use more OS resources, and therefore may not scale well in certain environments, such as high-volume Internet e-commerce servers.

Figure 1.1. Alternative Connection Multiplexing Strategies

Additional information on the design and trade-offs of connection multiplexing strategies is available in [SMFGG01, SSRB00].

Logging service Our networked logging service implementations use the connection-oriented TCP/IP protocol to transmit log records from client applications to a logging server. Connection setup overhead is amortized by establishing a connection once and caching it for the duration of the client/server conversations. The connections are nonmultiplexed, with each logging client application opening a separate TCP connection to the logging server.

The choice of TCP does require us to implement a data framing mechanism atop TCP bytestreams (which we show in Sidebar 9 on page 86). The ubiquity of TCP makes this effort pay off, however, in terms of interoperability and portability across OS platforms and data link layer networks. Moreover, the transport layer, not the application, is responsible for flow and congestion control, retransmitting lost packets, and ensuring the data is delivered in the proper order. These capabilities are important for networked applications that can't afford to lose log records.

I l @ ve RuBoard