So far in this chapter we have taken a rather abstract view of
communication services; specifying their behaviour in terms of a set of
primitive operations that may be performed upon them. If these services are
to be realised on systems, then these primitive operations will need to be
mapped to constructs in a programming language. In a conventional language
such as 'C', it is natural to make a correspondence between the abstract
primitive operations and function calls; the parameters of the primitive
operations becoming the parameters of the function calls. For the Transport
Service considered earlier we might have:
verbatim45
There are many decisions still to be made about how these functions should
behave. Some of the key ones are:
-
How is the interaction with the service to be synchronised? For
example, when a function returns does it mean:
-
The request has been accepted by the service and will be carried
out at some time in the future.
-
The request has been accepted and a request has been transmitted.
-
The request has been received by the remote entity.
-
The operation is complete this
would mean that a T_CONNECT_CONF had been received.
-
How are 'asynchronous events' like the unexpected receipt of data to
be handled?
-
How are the parameters to be represented as types from the language?
-
How are the buffers which carry the user data to be handled? Usually
buffers are obtained from a pool to which they must subsequently be
returned. Which layer should request the allocation and which should
request the freeing?
There are no 'best answers', to these questions and different implementors
will make their own choices. They are free to do so since, as yet, there
are no standards for programming interfaces. This is a little unfortunate
since it might have been hoped that one benefit of standardisation would
have been the easy portability of service implementations. We can now see
that two implementations can conform to an OSI service in an exemplary way
but be completely incompatible with respect to programming interfaces.
Mapping one such interface to another is by no means a trivial task.