This section summarises the content on this page (read on for the full tutorial):
|Clients||Socket, SockOpt, GetAddrInfo or GetHostByName, Connect, Send, Receive, Shutdown, Close|
|Servers||As clients but Connect is replaced by a Bind, Listen and Accept sequence|
|Other||Select, GiveSocket, TakeSocket|
Operating systems provide many facilities/services to the programs that will run on them, access to the file system is one of these, access to an IP network using the TCP protocol is the facility this tutorial is interested in. The interface for applications to use this facility or service is called the Application Programming Interface (API) and is primarily defined by a set of functions and their associated parameter lists.
Sockets programming provides a (relatively) simple method for allowing an application to communicate across an IP network. The API is simple, things only become complicated as we attempt to avoid waits for data that never arrive, support multiple connections or do other work while waiting for input from the user. Fortunately for the simplest client applications this complexity need not be relevant.
Sockets have been around a long time, the first release on BSD UNIX was about 1982. They were accepted as part of the initial POSIX standard in 1990. While System IV UNIX introduced a TLI (Transport Layer Interface), superseded by XTI (X/Open Transport Layer Interface), these standards have slowly been dropped/merged in favour of sockets.
Sockets are ubiquitous; a sockets API (application programming interface) is available on just about every OS (operating system) in use today. The API is available for many programming languages from IBM mainframe assembler, through compiled languages such as C and onto interpreted languages such as PHP, LUA and REXX. While some OS's include a specialized TCP API that exploits unique features of the OS for greater efficiency or simplified programming effort, the names of socket API calls are often still used when discussing communicating applications especially when these are on different platforms.
An Application Programming Interface (API) provides standardized access to a system provided service, in our case the TCP/IP stack ("Stack" refers to the layered protocols used to implement TCP communications e.g. TCP layer, IP layer, device driver layer, ethernet card and firmware. See the TCPIP Networking Tutorial for more details). Specifically the sockets API is a set of stack interfaces that enable an application (business logic, game, messaging etc) program to easily communicate with other applications across the TCPIP network.
In the case of sockets programming the first communications oriented call is the socket request. This request allows the Stack to initialize necessary features and returns a token, the socket number, to allow the application to identify this connection on all future requests to the API. It is therefore the glue between the application, and the Stack's representation of the connection. Typically an application will obtain a socket for each connection, whether that be a connection to be established, as in client mode communications or a connection from an external client that is to be accepted in the server model.
Typically we speak of TCPIP sockets and connections, however sockets can also be used with the UDP protocol, some APIs even provide a 'raw' interface that allow ICMP protocol support but this goes beyond the scope of this tutorial. This tutorial uses examples based on communicating applications using the TCP protocol.
These requests are:
|Socket||Establish a (active) socket for a client connection.|
|SockOpt||Set optional features for the socket.|
|GetAddrInfo||Interface with DNS to determine the IP address for a given host name e.g. microsoft.com, the address family (IPv4 or IPv6) and the port number for a specified service (provided this is registered with the DNS). GetAddrInfo also supports IPv4 and IPv6 addresses as input. Output is a list of address structures each of which can be used for connect requests.|
|Connect||Attempt to connect to a remote server, with given IP address and port number.|
|Send and Receive||Send data and Receive data on the connection. Note both a Write and Read option exists as well, however, these now simply restrict data flows to a subset of the Send, Receive capabilities.|
|Shutdown||Orderly shutdown of the connection to the remote server.|
|Close||Close the socket opened with a SOCKET call.|
More information on sockets programming for client applications is available via the links
For servers we still use the SOCKET, SOCKOPT, SEND, RECEIVE, SHUTDOWN and CLOSE requests, but instead of CONNECT we use the following:
|Bind||Issued after the SOCKET request, BIND informs the API that this socket should be tied (bound) to a particular port number (this allows connecting clients to implicitly find the App).|
|Listen||Informs the API that this is a passive socket that should wait for connection requests from remote clients.|
|Accept||Informs the API to create another (active) socket on which the current inbound connection request should run. Like socket this API call returns a socket number for the new connection.|
It's a little more complicated than this but we'll look at the detail on sockets programming for servers via these links
|Init||Some OS's do not support direct calls to the sockets library but require some basic linkage and/or environment be established prior to any calls e.g. IBM's mainframe sockets implementation requires an INITAPI call.|
|Select||This is the call that allows us to wait on multiple connections and/or a timer.|
|Term||Terminates the linkage/environment created via an init call.|
More information is available here
Secure Socket Layer (SSL) and the later Transaction Layer Security (TLS) are protocols for establishing secure, authenticated connections and for the subsequent support of encrypted data flows. Of themselves SSL and TLS do not require more than the send and receive of data between two communicating applications and are therefore supported through socket send and receive functions. The sockets application programmer must choose either to write all the necessary protocol support and encryption algorithms required or, more sensibly, to add an additional layer to the application e.g. that provided within Unix and Windows through OpenSSL. IBM zOS provides a general purpose PAGENT enabled AT/TLS facility, a C based System SSL and now with V2 the zOS client web enablement toolkit.
Note that after coding for secure connections you will still need to manage server and possibly client certificates on each system to run your application, this of itself is operating system dependent and non-trivial work.
Coding and implementing a secure communications solution will always involve greater effort and may require the use of many different teams dependent upon organizational structure, however, it would be totally irresponsible to deploy all but the most trivial non-secure application across the internet.