| Process-ID based FD protocol. The existence of a process will be tested
via the process ID instead of message based pinging. In order to probe a process' existence, the application (or
some other protocol layer) has to send down a SET_PID event for the member. The addresses of all members will
be associated with their respective PIDs. The PID will be used to probe for the existence of that process.
A cache of Addresses and PIDs is maintained in each member, which is adjusted upon reception of view changes.
The population of the addr:pid cache is as follows:
When a new member joins, it requests the PID cache from the coordinator. Then it broadcasts its own addr:pid
association, so all members can update their cache. When a member P is to be pinged by Q, and Q doesn't have
P'd PID, Q will broadcast a WHO_HAS_PID message, to which all members who have that entry will respond. The
latter case should actually never happen because all members should always have consistent caches. However,
it is left in the code as a second line of defense.
Note that
1. The SET_PID has to be sent down after connecting to a channel !
2. Note that if a process is shunned and subsequently reconnects, the SET_PID event has to be resent !
3. This protocol only works for groups whose members are on the same host . 'Host' actually means the
same IP address (e.g. for multi-homed systems).
| 