The technology called sockets is used to enable high level applications and services to communicate using the network hardware and protocol services offered by the operating system. This section will provide information about sockets and TCP/IP covering both UDP and TCP. Sockets are also used for other protocols like Netware's IPX/SPX. The examples in this section will be restricted to TCP/IP.
TCP/IP offers two types of ports software systems can use to communicate: TCP ports and UDP Ports.
TCP (Transmission Control Protocol) offers a reliable end-to-end connection using an unreliable network. UDP (User Data Protocol) is a connectionless transport protocol used to send datagram packets. Although unreliable, it is fast because of the small protocol overhead.
Network traffic by design is asynchronous. That means a software system and especially a service do not have influence on when traffic arrives. Although most operating systems today engage multitasking technologies, it would be a waste of resources to let each task poll for incoming events continuously. Instead, the operating system ensures to capture all traffic of a network interface using asynchronous event technologies such as hardware interrupts. Tasks use a blocking operating system call to wait for incoming data -- blocking means that the tasks remains suspended until the event it waits for occurs.
A socket can be seen as a mediator between the lower level operating system and the application. Roughly the socket is a queue. The higher-level application asks the operating system to listen for all messages arriving at a certain address, to push them into the socket queue and to notify the caller after data has arrived. To remain synchronous, operating system calls like listen(), accept(), receive(), and recvfrom() are blocking calls. That means the operating system puts the thread or process to sleep until it receives data. After receiving data and writing it into the socket queue, the operating system will wake the thread or process. The abstract system structure of a set of agents communicating via sockets is shown in figureA.3.
Figure A.4 shows a detailed view. Sockets are managed by a socket communication service, which provides the socket API to the communiction partners, i.e. the different application components. Using this API it is possible to setup and use sockets without any knowledge about the data structure of sockets and the underlying protocols used for communication.
The TPC protocol supports connection based communication. So before communication is possible a connection has to be established using a distinguished setup channel. That's why, with TCP, a service waiting for incoming connections has to employ two different types of sockets. One socket type has to be used for receiving connection requests and establishing connections. After a connection request arrived, another socket type has to be used for data transfer with the entity that issued the request. The client uses the same type of socket to establish a connection.
The first type, generally referred to as the ``dialup socket'' or ``server socket'' or ``listen socket'', is bound to one or more local IP addresses of the machine and a specific port. After a connection was requested by a remote application, a new socket usually called ``connection socket'' is created using the information of the packet origin (IP address and port) and the information of the local machine (IP address and port). This socket is then used for communication via the TCP connection. Figure A.5 shows the different kinds of sockets and the operating system calls to use and control them. Figure A.6 illustrates the relation between ports and connection resp. dial-up sockets.
Basically, a listen socket only contains information about the local port and IP address, it is therefore only used to listen, as the operating system would not know where to send information. The connection socket contains both origin and local information and can therefore be used to transmit and receive data.
There may be multiple TCP sockets (one listen socket and an undefined number of connection sockets) for each port. The operating system decides based on the information of the communication partner to what socket the received information has to be queued.
UDP Ports do not engage connection oriented techniques or safety mechanisms. Therefore a UDP socket is created using the local IP address and the port number to be used. Only one socket can be created for one port as a UDP socket is never associated with a connection partner. For sending, a host has to supply information about the communication partner; for receiving, it is optional.
In a multitasking environment multiple threads or processes that each serve a separate communication partner would, unlike in TCP, not have an own socket but share the socket. When receiving and transmitting they will then supply the address of their communication partner. As HTTP is based on TCP when used in TCP/IP networks, UDP is not used in Apache.
 |
Apache Modeling Portal 2004-10-29 |
