RESERVE: get exclusive use of a camera

This page is part of the ING document INS-DAS-24: client-server interface for control of cameras

Purpose: prevent interference between clients.

Actors: one UltraDAS client; one other client; udas_camera server.

Outline: the first client reserves the principle functions of the camera server. The second client tries to use these functions but is denied. The first client then finishes with the server and hte second client can have a go.

Normal course of events:

Two UltraDAS clients, c1 and c2 say, each want to do a sequence of operations on server.
C1 invokes the RESERVE action on server, with no arguments.
Server confirms c1's reservation by sending back a trigger message; RESERVE is still in progress but now goes to sleep.
C1 begins its action sequence.
C2 invokes RESERVE on server, with no arguments.
Server sends the error-status DITS__ACTACTIVE to c2.
C2 gives up for a while.
C1 finishes its sequence.
C1 kicks the RESERVE action on server, sending no arguments with the kick message.
Server sends back good status for RESERVE to c1.
C2 tries again: it invokes RESERVE on server with no arguments.
Server acknowleges C2's reservation with a trigger message.
C2 is now free to do its sequence.

Variations:

C1 exits (crashes, is killed by the user, is buggy) without doing step 10. DRAMA does the kick automatically when c1 disconnects; the rest of the use case follows normally.
C1 hangs up and does not disconnect. C2 is locked out indefinitely.
C2 is badly written; it starts its action sequence without getting a reservation, while c1's sequence is in progress. The server and both clients get horribly confused and the system falls in a heap.