Understanding Sockets in Unix, NT, and Java
By Ken Nordby2003-05-26
Further study
|
|
If this paper has whetted your appetite for more study of sockets, there are many aspects of sockets usage that you can profitably investigate. Here are some examples:
Unix Domain
The socket domain parameter signifies the communications environment-- the type of network and address space-- through which connected machines will communicate. For example, the Internet domain, indicated by AF_INET, consists of machines connected to an intranet/Internet and using the Internet Protocol addressing scheme. The original version of sockets also supported a "domain" that consisted of a single Unix machine. This domain is specified with the AF_UNIX symbolic constant. Generally in software development Unix domain sockets are treated like other types of sockets, but addressing in this domain consists of specifying file names rather than network addresses. Since this communications domain is defined specifically for the Unix environment, implementations of sockets on non-Unix systems may not always support this type of domain.
Programming with Datagrams
The socket type parameter is typically set to SOCK_STREAM or SOCK_DGRAM, although other values are supported. SOCK_STREAM indicates that sockets communication will be connection-oriented, and this is the value used in the sample application. In this arrangement data transmission takes place in the context of a session in which both machines are logically connected. Data delivery is considered reliable, and messages arrive in the order in which they were sent. In the Internet domain, the Transmission Control Protocol (TCP) is used for messages of this type.
The value SOCK_DGRAM indicates that sockets communication will be connectionless. Sockets do not need to be connected in order to transmit data, which is transmitted in discrete packets called datagrams. Data transport is not considered reliable, and packets may arrive out of order or not at all. The User Datagram Protocol (UDP) is used for messages of this type. Despite the lack of reliability, connectionless protocols like UDP are useful in certain situations. For example, UDP communication is faster than TCP; it does not incur the overhead of setting up a session and maintaining state.
Concurrent Servers
The server program in the sample application is an iterative server because it processes client requests one at a time. Real servers, however, tend to be concurrent servers. A concurrent server leverages multiprocessing and/or multithreading capability provided by the platform to serve multiple client requests in parallel. The precedent was established in the Unix world, where the fork() system call was available to spawn child processes. In modern Unix implementations Posix thread support is available in the pthreads library, and concurrent servers can choose between processes or threads to handle multiple concurrent requests. Non-Unix platforms such as Windows NT and OS/2 also have threads capability.
When a server supports concurrency, the relationships among the sockets is sometimes referred to as master-slave. The master socket is the one which is bound to the server's network address: this socket's task is to listen for requests, but not to service them. When a client request is accepted by the master socket, the accept() call creates a new socket that is dedicated to supporting the client that launched the request. This "slave" socket handles all data transfer between the server and its assigned client, and can be discarded when the client request has been satisfied. The master socket continues to accept client requests and create new processes or threads up to the system's capacity. Concurrent servers are challenging to develop and require competency not only in sockets technology but also in managing multiple processes or threads. For high-demand servers with a high client-to-server ratio, concurrent servers are clearly preferable to iterative servers.
Variations in Sockets Support
Platforms which added sockets support based on the original BSD Unix version are not always completely consistent. Basic calls such as socket ( ) , bind ( ) , and connect ( ) are likely to be identical to the Berkeley version in syntax and semantics, but other calls can reflect variations attributable to platform differences. Following are some examples:
- Microsoft Windows 3.x
In the Windows environment, we have already observed the WSAStartup ( ) call that is required to load and initialize the winsock code. Because Windows 3.x is a single-threaded operating system, sockets calls that block in the original BSD version would freeze the Windows system. Some existing calls were modified, and some new calls added, to enable sockets functionality in a single-threaded environment. - IBM AIX
Variations in socket support can affect not only which function calls are provided but also the range of argument values available for sockets calls. For example, the most common socket domains are AF_INET (Internet domain) and AF_UNIX (Unix domain). AIX 4.2, however, adds the AF_NDD (Network Device Driver) domain. The NDD domain supports transmission of data packets at a lower layer in the protocol stack than is normally available, for example, addressing packets directly to a Medium Access Control (MAC) address. - IBM OS/400
In Unix an executing process can pass a file descriptor or socket descriptor to another process. In the IBM OS/400 operating system there is no way to pass a socket descriptor from one job to another. Therefore the sockets support on this platform added the functions givedescriptor( ) and takedescriptor( ) .
Tutorial Pages:
» Understanding Sockets in Unix, NT, and Java
» Basic sockets concepts
» A simple example
» Sample sockets application
» Server program (Unix)
» Client program (NT)
» Client program (Java)
» Further study
First published by IBM DeveloperWorks
