next up previous contents
Next: 5 High-Level System Design Up: 4 Problem Documentation and Previous: 4.2 The Notion of

4.3 The eXtended User Datagram Protocol (XUDP)

The primary goal of this MQP was to develop a method by which real-time multimedia data could be optimally transferred over the Internet. After determining that neither the Transmission Control Protocol nor the User Datagram Protocol were up to the task, common-sense reasoning on the nature of multimedia data prevailed, providing an optimal method, timed obsolescence. Timed obsolescence, attempts to preserve, above all, the linear time relationships of timed sequential data. As it stands, this concept necessitates some amount of lossiness or semi-reliability in the delivery mechanism - a rarely expressed quality of an internetworking transport layer protocol.

A thorough implementation of timed obsolescence would require an entirely new transport layer protocol that combines the best-effort delivery capability of UDP with the optimized flow control mechanisms of TCP. The protocol could be implemented on top of UDP, utilizing UDP as an interface to IP, with a quick checksum and I/O multiplexing.

Four thousand lines of C code and several months later, a fully-functional robust implementation of timed obsolescence was produced as an extension to UDP; the eXtended User Datagram Protocol or XUDP is entirely capable of preserving the linear time relationships inherent in multimedia data.

Much of XUDP's functionality lies in the adoption of a new unit of internetworking data transfer named the parcel. A parcel is a single unit of inseparable data that is defined by the user's application, such as a frame in a video, a one second burst of audio or any number of imaginable constructs that require delivery as a whole. The size of each parcel is set at the time that the parcel is sent from the application; XUDP currently supports parcel sizes from 1 byte to 32KBytes.

Because of the unknowable conglomeration of hardware and software that make up the network layer, a possibility exists that an XUDP parcel will not be able to pass atomically through the network. The actual transmitted unit of data on an internetwork is referred to as a packet. If a parcel is small enough, it may fit within a single packet of data (typically around 512 bytes). However, if, in the likely case that the parcel is larger than the maximum allowable size of a packet, the parcel is fragmented into many separate packets that contain position indicators (sequence numbers) unique to that particular parcel. The receiver guarantees that parcels will be reassembled completely and in order from the string of packets that comprise it.

In the case that packets become lost in the network, retransmission will take place selectively at the packet level, until they have been successfully acknowledged allowing XUDP the capability of full reliability if so required by the application and requested as the mode of service from XUDP.

XUDP is capable of sending the parcel in one of three modes:

  1. Full reliability: parcels are guaranteed to be received at the remote application in a timely manner. XUDP's ability to retransmit packets guarantees that all of the data in a parcel will be received by the application.
  2. Semi-reliability (timed obsolescence:) parcels are stamped with a time-to-obsolescence (sell-by time or expiration time). If the XUDP server detects that the entire parcel will not be received before the time expires, all data related to the parcel, whether acknowledged or unacknowledged, is removed. This allows XUDP to conserve network bandwidth for the purpose of sending data that is still useful.
  3. Best-effort, one shot delivery attempt: Similar to the service provided by UDP, this delivery method offers no chance of retransmit.

Research has shown that there is not any product in existence at the completion of this project that provides, or attempts to provide any service similar to timed obsolescence. Therefore, the product developed during the course of this project is able to provide a unique, unmatched service to the networking community.

Chapter 5 contains a detailed description of the functionality and implementation of XUDP. This is followed by a sample application developed to test XUDP, presented in chapter 6 and by an exhaustive presentation of XUDP's source code in chapter 7.


next up previous contents
Next: 5 High-Level System Design Up: 4 Problem Documentation and Previous: 4.2 The Notion of

Mike Andrews
Wed Mar 19 16:07:58 EST 1997