... sender^3.1

This work only if the request was a multicast request, so all members received (and stored) a copy of the request.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... it^3.2

Local delivery can be turned on/off using SetOpt.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... false^3.3

A member will never retrieve the state from itself !

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... channel)^3.4

Note that the channel currently has to be connected, otherwise an error message is issued.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... buffer^3.5

See 3.1.10 for two helper methods to serialize/unserialize objects to/from byte arrays.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... stacks^3.6

See 4.3 for a detailed discussion of this division.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... members)^3.7

If no suspicion service is available, timeouts can be used instead.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... ./JavaGroups/JavaStack/Protocols^3.8

The location of the directory may change in th future.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... method^3.9

If in doubt what properties are accepted by a layer, this method can always be consulted in the source code.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... broadcasting^3.10

The terms multicasting and broadcasting are used synonymously in the user's guide.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... it^3.11

To do so, JRouter has to maintain a table between groups, member addresses and TCP connections.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... daemons^3.12

The alternatives outlined below are currently (March 1999) not implemented. However, the modifications proposed should not be difficult to implement.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... downloaded^3.13

This is changed in JDK 2.0 with the improved security model.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... JChannel^4.1

However, exceptions is the JChannel protocol stack, caused by a malfunctioning protocol, are caught at the JChannel level, and can therefore not cause havoc to the channel itself. Yet, malfunctioning protocols may affect messages (adding wrong headers, modifying message contents, or dropping messages), therefore the reliability of a protocol stack is the sum of the robustness and reliability of all its layers.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... views^4.2

Virtual synchrony does not guarantee any ordering properties for the messages between views, this would have to be handled by a separate layer (e.g. TOTAL).

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...^4.3

File JavaGroups/Event.java will always be the most current source of information concerning events.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... stopped^4.4

For initialization and de-initialization see 4.1.6.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... message^4.5

The overridden method could possible reorder or even discard the message altogether.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... buffer^4.6

Using Util.DefragmentBuffer, cf. 3.1.10.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... result^4.7

RpcProtocol assumes that all communication is done via method calls, therefore it will not process other objects. However, the implementation of Handle could be overridden to allow this.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... stack^5.1

Note that in some cases ordering may not be strict (e.g. no FIFO ordering required). In such a case, concurrency could be introduced.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

...^5.2

A similar (circular) deadlock situation is shown in fig. 5.2.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... P^5.3

For simplicity excluding the sender of the request that caused P to send m1.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... requests^5.4

Note that only synchronous requests are tagged with call chains, asynchronous requests will never cause the sorts of deadlocks described above, because the caller does not wait for their completion.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... one^5.5

This is different from causal order [Bir96, ch. 13.12.6] which records potential causality between message reception and sending, as it has no means to detect real causality.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... them.^6.1

This is for example possible by switching from a NAK-based to an ACK-based scheme.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... messages'^6.2

Note that if no STABLE layer is present underneath, all messages in 'sent messages' will be returned ! However, the 'sent messages' store is cleared whenever a new view is installed.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... it^7.1

Except when the suspected member is the coordinator: in this case, the next member in rank takes over and becomes the new coordinator. Decisions based on member ordering are possible because ordering is always deterministic. This means that no distributed election algorithm needs to be run. The coordinator is commonly the first member.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... 0^7.2

This is not yet implemented, therefore MNAK is not usable at the time ! It will be implemented when the FLUSH protocol is written.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... stack^7.3

Not yet available as of March 99.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... state^7.4

Note that the data type of the state has to be serializable as it will be marshaled/unmarshaled to be sent over the network. If this is not the case, an exception will be thrown.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

... member^7.5

If Channel.GetStates() was called, then this message will be sent to all members instead.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.