Image Processing Reference
In-Depth Information
Client process
Server process
Client process
Server process
Request Confirmation
Response
Indication
Request Indication
Request
Indication
1
4
3
2
1
4
3
2
Client
Server
Client
Server
FIGURE .
Communication services used in the client-server model (left: normal; right: based on unconfirmed
services).
of PROFIBUS-FMS (in similar form they exist also in Foundation Fieldbus and WorldFIP), the ser-
vices comprise the following groups: variable access (read, write), transmission of events, execution
of programs, domain management (up- or download of large amounts of data), context management
(administration of communication relationships), and object dictionary management (administra-
tion of the list of all objects in a device). Depending on the actual service requested, the semantics of
the information exchanged obviously differ.
In some cases, and deviating from the standard model described before, a client-server communi-
cation can also be built from two unconfirmed services (Figure ., right side). his means that the
response generated by the server is not related to the request by means of the underlying protocols
(i.e., it does not generate a confirmation on the local application layer). Rather, the client application
hastokeeptrackoftherequestandneedstorelatetheindicationgeneratedbytheresponseonits
own. his mechanism reduces the implementation efforts on the protocol side at the expense of the
application complexity. Another—nonstandard—variant of the client-server model may have several
responses from the server answering a single request []. Such an approach can be beneficial if the
service execution on the server side takes a long time, so that partial results are reasonable or at least
indications about the status of the execution. This may help circumvent problems with, e.g., hard-
coded timeouts in legacy client applications by means of some keep-alive signal. Somewhat related to
this and resembling a publisher-subscriber-type operation is a multi-response from a server follow-
ing one single request from the client. his can be useful if strictly periodic data transmissions from
the server are required. Contrary to a cyclic client-server polling strategy which always is affected by
network and software delay, the server can control the sampling and transmission period of the data
to be sent in a better and more accurate way.
As far as the interrelation of the client-server model and MAC strategies is concerned, it should
be noted that basically, a client-server-type communication can be implemented in both mono- and
multi-master systems. In the latter cases (which may be based on CSMA, TDMA, or token passing),
every master can take on the role of a client, whereas in mono-master systems (polling-based or
centralized TDMA) this position is reserved for the bus master. Consequently, the client-server
paradigm is used mainly for master-slave systems (as represented by PROFIBUS, AS-I, MODBUS,
P-NET, BITbus, INTERBUS) and for reliable data transfer on application level (e.g., for parameteri-
zation data, file transfer, network and device management). In particular for management functions,
the client-server model is widely used also within fieldbus systems that organize their regular data
transfer according to the publisher-subscriber model, such as WorldFIP, EIB, CANopen, DeviceNet,
ControlNet, or LonWorks.
20.5.5.2 Publisher-Subscriber Model
The basic idea of the publisher-subscriber model is that certain nodes (the publishers) produce
information which they post into the network. The subscribers are typically groups of nodes that
listen to information sources. Relating publishers and subscribers can be done at runtime. The
