Chương 2. Ứng dụng TCP/IP & Intranet
2.2 Xây dựng ứng dụng trên tầng Transport
2.2.4 Application programming interfaces: The socket API
The socket interface is one of several APIs to the communication protocols.
Designed to be a generic communication programming interface, it was first introduced by the 4.2BSD UNIX-based system. Although the socket API for IPv4 was never standardized, it has become a de facto industry standard, and RFC 3493 was created to update the API for IPv6. More advanced IPv6 socket programming can be found in RFC 3542.
The socket interface is differentiated by the following services provided to applications:
_ Stream sockets services
Stream sockets provide a reliable connection-oriented service such as TCP.
Data is sent without errors or duplication, and is received in the same order as it is sent. Flow control is built in to avoid data overruns. No boundaries are imposed on the exchanged data, which is considered a stream of bytes. An example of an application that uses stream sockets is the File Transfer Protocol (FTP).
_ Datagram sockets services
Datagram sockets define a connectionless service such as UDP. Datagrams are sent as independent packets. The service does not guarantee successful delivery of the packets; data can be lost or duplicated, and datagrams can arrive out of order. No disassembly and reassembly of packets is performed.
An example of an application that uses datagram sockets is the Network File System (NFS).
_ Raw sockets services
Raw sockets allow direct access to lower layer protocols, such as IP and ICMP. This interface is often used for testing new protocol implementations. An example of an application that uses raw sockets is the ping command.
Additional information about sockets is in 4.1.2, “Sockets” on page 145. Socket APIs provide functions that enable applications to perform the following actions:
_ Initialize a socket
_ Bind (register) a socket to a port address _ Listen on a socket for inbound connections _ Accept an inbound connection
_ Connect outbound to a server _ Send and receive data on a socket _ Close a socket
Though the specific details of the previous functions will vary from platform to platform, the industry standard is based on Berkeley sockets, also known as the BSD socket API, released in 1989. Additionally, RFC 3493 was created to define the extensions needed for socket APIs to incorporate IPv6. The core functions made available by industry standard APIs are as follows:
_ Initialize a socket Format:
socket(domain, type, protocol) Definitions of fields:
domain This is the protocol family of the socket to be created. Valid
values include PF_INET (IPv4) and PF_INET6 (IPv6).
Additional platform-specific values can also be used.
type This is the type of socket to be opened. Valid values typically include stream, datagram, and raw.
protocol This is the protocol that will be used on the socket. Values typically include UDP, TCP, and ICMP.
_ Bind a socket to a port address Format:
bind(sockfd, localaddress, addresslength) Definition of fields:
sockfd This is the socket that is to be bound to the port address.
This is the value obtained previously from the socket function.
localaddress This is the socket address structure to which the socket is bound.
addresslength This is the length of the socket address structure.
_ Listen on a socket for inbound connections Format:
listen(sockfd, queuesize) Definition of fields:
sockfd This is the socket on which the application is to listen. This is the value obtained previously from the socket function.
queuesize This is the number of inbound requests that can be queued by the system at any single time.
_ Accept an inbound connection Format:
accept(sockfd, remoteaddress, addresslength) Definition of fields:
sockfd This is the socket on which the connection is to be accepted.
This is the value obtained previously from the socket function.
remoteaddress This is the remote socket address structure from which the connection was initiated.
addresslength This is the length of the socket address structure.
_ Connect outbound to a server Format:
connect(sockfd, remoteaddress, addresslength) Definition of fields:
sockfd This is the socket from which the connection is to be opened.
This is the value obtained previously from the socket function.
remoteaddress This is the remote socket address structure to which the connection is to be opened.
addresslength This is the length of the socket address structure Definition of fields:
sockfd This is the socket on which the application is to listen. This is the value obtained previously from the socket function.
queuesize This is the number of inbound requests that can be queued by the system at any single time.
_ Accept an inbound connection Format:
accept(sockfd, remoteaddress, addresslength) Definition of fields:
sockfd This is the socket on which the connection is to be accepted.
This is the value obtained previously from the socket function.
remoteaddress This is the remote socket address structure from which the connection was initiated.
addresslength This is the length of the socket address structure.
_ Connect outbound to a server Format:
connect(sockfd, remoteaddress, addresslength) Definition of fields:
sockfd This is the socket from which the connection is to be opened.
This is the value obtained previously from the socket function.
remoteaddress This is the remote socket address structure to which the connection is to be opened.
addresslength This is the length of the socket address structure An example of a client/server scenario
Figure 11-2 illustrates the appropriate order of socket API functions to implement a connection-oriented interaction.
The connectionless scenario is simpler in that the listen(), accept(), and connect() functions are not invoked. Table 11-1 compares the socket API functions that are used for connection-oriented and connectionless clients and
servers.