Reservation Protocol Proposal

This is a proposal for a general-purpose protocol for “reserving” resources, e.g. reserving unique access to a locomotive node or reserving unique access for memory-configuration protocol. It grew out of (and in some places is a cut&paste from) capability in the memory-configuration protocol.

Note that this has not been agreed to by the general OpenLCB group. It's just a proposal. Details will change.

The basic idea is to provide a test-and-set approach to reservation. It goes through datagrams (but could be modified to use message level, which might be a bood idea if the messages can be kept short enough).



To have a general-purpose protocol for reserving things, you have to specify what those things are. They're accessed within a specific node via addressed messages, so NodeID doesn't have to be part of the resource identification. But you need to have several, so that a given node can be separately locked for e.g. memory-configuration protocol, and also 5 different times for the 5 locomotives it's controlling.


Send the following datagrams to reserve, release, etc.


Datagram Protocol ID byte

Resource Selection Byte




(6 bytes)

Lock/Reserve Reply


(6 bytes)

The configuring node sends a Lock datagram with its NodeID. If no node has locked this node, indicated by zero content in the lock memory, the incoming NodeID is placed in the lock memory. If a node has locked this node, the non-zero NodeID in the lock memory is not changed. In either case, the content of the lock memory is returned in the reply. This acts as a test&set operation, and informs the requesting node whether it successfully reserved the node. To release the node, repeat the lock operation with a zero NodeID. The lock memory is set to zero when the node is reset.

If receiving node doesn't implement the particular resource, it should reply with an error instead of Lock/Reserve Reply. (Another reason to go with messages instead of datagrams, because Optional Interaction Rejected has better error code semantics)

Remaining Issues

This grew out of the datagram-based configuration protocol, but should probably be just made into two messages. That occupies the same space, and removes the need to acknowledge the datagrams. The messages are small and have immediate execution, so there's no problem with having them be messages.

To ease implementation, zero should not be a valid resource ID.

Local vs global reserved-object IDs

Reservation involves at least 3 nodes: the one with the resource being reserved, the one holding the reservation, and one or more others who'd like a reservation but can't get it right now.

The one holding the resource doesn't actually need to know about the resource ID, as the reservation status doesn't change its actions (it's a reservation, not a lock).

But the others have to agree on the value for the system to work.

That indicates you need either a set of well-known global IDs, or a way to ask about locally defined IDs.

The writeup above is mostly about former. IDs are well known and associated with a particular protocol: "reserve use of configuration protocol".

But you might want to have a more general mechanism that can reference e.g. 1-of-n objects in a node: "reserve use of 5th virtual thing"

That would require more protocol support, but certainly could be done. If you want that someday, this protocol should stay in datagrams to have expansion room.

Site hosted by

This is SVN $Revision: 2215 $