For many years the OSI reference model was the core reference framework used by all communications courses. It remains a theoretical reference model that can be used to compare protocols and stacks. A typical OSI communications is sketched below.
Assume that one end system (local computer) has a client program which requires the services of a remote server program located at a remote computer connected by a communications network. A simplified diagram is shown in the figure below. This shows the peer-to-peer communication.
Client / Server interaction across a packet data network
The diagram above provides only a very simplified view of what happens. In fact, a number of primitives are required to perform even such simple communication. The text belows performs a detailed analysis of the primitives and PDUs which are exchanged.
The user executes the client program and attempts to send one piece of data to the server (for example,. a request to lookup the address corresponding to a name). The actual data need not be of concern here. Before the client may send the data, it must first establish a connection to the application layer (i.e. communications software library) on the local computer.
The client program uses an A-Associate request function call to start the communication session. Once the application layer has initialised, it contacts the presentation layer, sending a P-Connect request primitive (see below). This establishes the format of the data to be used and the data formats which are to be supported by the system A on the network. This information is sent to the session layer as an SDU with a S-Connect request primitive. The session layer allocates a session identifier, and selects appropriate protocol options to support the services requested by the application layer. The session layer also identifies the intended recipient of the communication (i.e. the remote computer).
Establishment of a connection between client and server (part 1)
The session layer proceeds to request a transport layer connection to the remote system using a T-Connect request. At this stage, the session layer may chose to not send the S-Connect SDU, and instead to wait to see whether the transport connection request succeeds. The transport request identifies the remote service required (i.e. the port identifier for the server) and the type of transport protocol to be used. The basic types of transport service are reliable and best-effort.
At this stage the transport layer requests the network layer to establish a connection to the remote system. The network layer service will normally have established a link layer connection (and a physical layer connection) to the nearest intermediate system. In this case however, we assume that all the layers must be connected.
Finally, the network layer connect packet is sent using the link layer service to the remote system. The system responds by invoking the requested transport layer, and establishing a transport layer connection. If the remote system is able, it will then confirm the establishment of the transport connection, and pass the confirmation back to the local client computer. At this time the two systems have a communications path using the transport layer service.
The transport layer may then use this service to request a connection to the server process on the remote computer . It does this by forwarding the original session layer SDU (which it had previously stored in the session layer of the local computer) as a transport layer packet. This passes across the network layer service, and at the remote system is passed to the session layer protocol.
The received SDU identifies the session ID and the application process with which the client wishes to communicate. The presentation layer is sent a S-Connect indication, containing the presentation options requested by the client and the A-Associate request sent by the client. The application layer now attempts to connect to the server process. (In some cases, a new server program will be activated to handle this new request).
Establishment of a connection between client and server (part 2)
Once this has succeeded a response is generated, carrying the final details of the connection. This information is passed as an A-Associate response primitive to the application layer. At each layer additional PCI is added by the remote system, and finally an N-Data primitive is sent across the network layer service. At the receiver each layer verifies the information it receives, and confirms the successful connection. The application layer send an A-Associate confirm message to the client process which is then ready to transmit data.
Transmission of data is accomplished similarly. The client application sends a Data Request primitive, along with the data, to the application layer, which adds its header and passes a Data Request primitive and Data Unit to the presentation layer. This process continues, with addition of appropriate headers, until it reaches the data link layer, which adds its header and passes the individual bits to the physical layer for transmission. The bits are received at the remote physical layer, and passed to the remote system data link layer. When the data link layer recognises the end of the data unit, it strips off the header and sends the remaining PDU to the network layer (by including it in a Data Indication primitive).
Data Indication primitives, with reduced data units, cascade up the layers until the application data reaches server application. Client application only learns of successful receipt if the server application returns an Acknowledgment (in this case, possibly with the requested data). The Acknowledgment returns across the network. The "association" has now been made and data may be sent across the network between the client and server.
After data transfer is complete, a disconnect phase similar to the connect phase will occur.