BIDCTL

NAME

BIDCTL (Bootid Control Protocol)

SPECIFICATION

BIDCTL is the control module of the BootId protocol. The BootId protocol is designed to advise workstations that a peer has rebooted, to protect protocols from receiving messages generated during previous boot incarnations, and to inform higher protocols of a peer's reboot in a timely fashion.

If an upper protocol registers with BIDCTL protocol and messages from its session pass through BID sessions, the BootId protocol guarantees that a message from a rebooted peer will not be sent to an upper protocol until the upper protocol has been informed of the reboot.

SYNOPSIS

Upper protocols register their desire to be informed of a peer's reboot by openEnabling BIDCTL with that remote peer's IPhost. When BIDCTL determines that the remote peer has rebooted, it informs all interested upper protocols via a control operation (see below.) If an upper protocol is no longer interested in learning about a peer's reboot, it may openDisable BIDCTL.

REALM

BIDCTL is in the CONTROL realm. There are no BIDCTL sessions.

PARTICIPANTS

BIDCTL openEnable and openDisable expect a single participant containing the IPhost of the remote peer.

CONTROL OPERATIONS

BIDCTL_PEER_REBOOTED:

Invoked by BIDCTL on registered upper protocols to inform them that a peer has rebooted. The id field of the BidctlBootMsg contains the new remote BootId. The upper protocol's control function should not block while handling this notification.

Input:

BidctlBootMsg == { IPhost h; BootId id; }

Output:

none

The remaining control operations are not necessary for most users of BIDCTL. They are provided mostly for the use of filtering protocols (e.g., BID) which work in conjunction with BIDCTL.

BIDCTL_FIRST_CONTACT:

Invoked by BIDCTL on registered upper protocols to inform them that an initial bootid for the given peer has been discovered. The id field of the BidctlBootMsg contains the new remote BootId.

Input:

BidctlBootMsg

Output:

none

BIDCTL_GET_LOCAL_BID:

Returns the current BootId of the local host.

Input:

none

Output:

BootId

BIDCTL_GET_PEER_BID:

Returns the last confirmed BootId of the given remote host. If the id field of the input structure is non-zero, it indicates a possible new value. If this value differs from BIDCTL's confirmed value for that peer, BIDCTL will start a handshake with the remote peer to determine a new confirmed value. The input id can be used by a filtering protocol to indicate that it has seen a new remote BootId value.

The BootId of the output structure will be 0 (an invalid BootId) if BIDCTL doesn't yet know the peer's BootId.

Input:

BidctlBootMsg

Output:

BidctlBootMsg

BIDCTL_GET_PEER_BID_BLOCKING:

Differs from BIDCTL_GET_PEER_BID in that the calling thread will block if BIDCTL has not yet learned the peer's BootId or if the suggested id field is non-zero and differs from the protocol's current value for the peer BootId. If the operation blocks, it will not release the calling thread until the peer BootId has been confirmed. There is no timeout.

Input:

BidctlBootMsg

Output:

BidctlBootMsg

CONFIGURATION

BIDCTL expects only its transport protocol below it. It will open the transport protocol with a single participant consisting of the remote IP host.

BIDCTL uses an internal checksum and works correctly in the presence of dropped messages, so a reliable transport protocol is not necessary.

As an optimization, BIDCTL can perform an IP local-net broadcast to inform interested peers that it has rebooted. A rom file entry of the form:

         bidctl bcast

         bidctl nobcast

AUTHOR

Ed Menze