The application layer consists of the Berkeley sockets-like interface in the user's application to the underlying XUDP architecture.
XUDP is designed to provide a lightweight transport mechanism for multimedia data through a Berkeley sockets-like API. As evidenced in earlier sections, the Berkeley sockets interface has successfully removed the complexities of the lower levels of network programming from the programmer's list of worries. Figure 5.1 shows the ideal final implementation, where all the details of network transmissions are completely hidden from the programmer's perspective, allowing the programmer to concentrate on developing a quality application, rather than building low-level internetworking routines.
Figure 5.2 displays to a greater extent the detail involved in the layering of the networking system. Found in the ``kernel level'' are the implementations of the UDP and IP layers, as well as the Network Interface Card drivers. UDP will provide an interface to IP, as well as a packet checksum and a port multiplexing function. IP provides a best-effort datagram delivery service and address handling for transport over the Internet. The NIC and physical layer are abstracted to include FDDI, Ethernet, ATM with AAL 5 or any physical networking medium.
The application layer needs to be concerned mainly with the presentation of transmitted and received data to the user. Packets will need to be sent, received and acknowledged independently from reads and writes to and from the user's application, but it is not consistent with layered protocol design techniques to require detailed input/output multiplexing on the part of the application layer. Therefore, in order for the flow control algorithms to function asynchronously without intervention from the application program, they must exist as a separate process.
Utilizing a separate process for the protocol implementation preserves the layered programming paradigm, leaving only those functions related to the API as a part of the user's process. However, this separation comes at the cost of an additional connection to move the data between the protocol's daemon process and the user's application. Fortunately, the connection exists only between two processes on the same machine, so it can be implemented with UNIX streams - yielding much lower system load than a TCP/IP implementation!
From the API programmer's perspective, XUDP is accessed through a series of high-level sockets-like functions: xudpSocket, xudpBind, xudpListen, xudpAccept, xudpConnect, xudpSend, xudpRecv and xudpClose. Figure 5.3 demonstrates how similar this interface is to the existing Berkeley sockets API (the diagram is purposely similar to Stevens' Figure 6.2[42, p.261,]).
Below, the API functionality is discussed briefly, for specific implementation details, refer to section 7.3.
xudpSocket connects the user process to the locally running XUDP server, informing it of its presence. For the sake of programming ease and abstraction, three separate UNIX stream connections will be formed between the user application and the XUDP daemon to distribute control information, audio data and video data. Figure 5.4 shows the stream connections graphically. Among other improvements, this will allow for easier multiplexing between the control information and the data to be sent to the foreign host.
XUDP is a connection-oriented protocol. A typical client/server pair developed using the Berkeley sockets API utilizes calls to socket, connect, bind, listen and accept. In a similar manner, programs developed specifically for XUDP will use xudpSocket, xudpConnect, xudpBind, xudpListen and xudpAccept. In fact, the XUDP ``socket'' functions are nearly drop in replacements for their representative Berkeley sockets functions.
In the case of a conventional client side application, after a XUDP socket is created with xudpSocket, the application will typically attempt to connect with a server application by using xudpConnect.
If the application is a server, it may change the UDP port number that the XUDP server utilizes to receive incoming connections with xudpBind. It can then proceed to instruct XUDP to listen for incoming connection requests with xudpListen and to block until a connection is accepted with xudpAccept.
In the operation of a complete point-to-point communications system,
XUDP daemon protocol servers will need to be started on each host
involved. A user application will ``place a call'' with
xudpConnect XUDP protocol server on a foreign host, where
the foreign server will connect the call if a user application has
registered with it (xudpSocket) and is prepared to accept
callers (xudpBind 
xudpListen xudpAccept.) Figure
5.5 shows this case with all layers present for our
typical example.
The basic unit of data transfer implemented by XUDP is the parcel. Bearing a good deal of resemblance to an IP datagram, the parcel is a variable-length block of data that is sent as a whole from the sending application and received as a whole by the receiving application. If the parcel is not marked as RELIABLE, and it expires before all of its data is completely received, the parcel is never delivered and the incomplete data is discarded. Parcels will never be delivered incompletely, either the entire parcel or, if timed-obsolescence is invoked, nothing will be received at the application layer.
Shown below is the C code that forms the host data structure that XUDP uses to identify connections (defined in xudp.h, instead of an integer file descriptor.
struct XUDPHost
{
int fdAudio; /* File descriptor of UNIX Stream */
int fdVideo; /* File descriptor of UNIX Stream */
int fdControl; /* File descriptor of UNIX
Stream */
struct sockaddr_in hostaddr;
struct hostent *pHostent; /* hostent structure for client */
};
XUDPHost structure.
XUDP maintains the application layer struct XUDPHost through calls to its API functions. The host data structure is intended provide a convenient storage facility for miscellaneous data pertinent to the connection. It keeps the three UNIX stream file descriptors handy for communication with the local XUDP server. The struct hostent * structure is defined in /usr/include/netdb.h and appears as follows on an OSF/1 V3.2 system:
struct hostent {
char *h_name; /* official name of host */
char **h_aliases; /* alias list */
int h_addrtype; /* host address type */
int h_length; /* length of address */
char **h_addr_list; /* list of addresses from name server */
#define h_addr h_addr_list[0] /* address, for backward compatiblity */
hostent structure.
Of particular interest to the conventional application programmer is the storage herein of the official hostname (in C style NULL terminated string form) for the connected endpoint. The hostaddr entry in the XUDPHost structure similarly holds the numerical IP and addressing information related to the connection endpoint.