Events and messages

The difference between events and messages is that events are used for intra-stack communication, whereas messages are used for inter-stack communication. That means that in a JChannel protocol stack, only events are passed between layers, whereas messages are exchanged between stack, i.e. put on the network and received from the network by the bottommost layer. Events are used to pass information relevant to a single stack between layers. Messages are wrapped in events by the bottommost layer and passed up the stack. When JChannel.Receive() is called by an application, if the event's content on the JChannel queue is a message, then it is 'unwrapped' and returned. When a message travels down the stack (wrapped in an event), the bottommost layer will unwrap the message and put it on the network.

An event has a type (integer) and an argument (object). Message events have for example type Event.MSG and as argument the message. The type of an event can be determined calling method Event.GetType.

The number and types of events used in JavaGroups is fixed and determined in file Event.java. However, in some cases, developers of new protocol layers might find it useful to add new event types. There are two possibilities: either a new event is added to Event.java, modifiying the source code, or the predefined event USER_DEFINED is used. The former solution requires feedback into the main distribution, otherwise a number of incompatible distributions might exist. Also, the same event type numbers might be chosen by different developers, requiring disambiguation when merging those modifications back into the original distribution. The latter allows developers to use their own event types, embedded in the USER_DEFINED event type. The user-specific event would be contained in the argument of the user-defined event. This has the advantage that no source code needs to be changed.

The types currently available for events are listed in table 4.1^4.3.

Table 4.1: Event types and their arguments

Event Type	Argument	Description
START	-	Sent up the stack. The protocol stack is started. Generates a response from bottommost layer. The layer may start its work now
START_OK	-	Response to START, generated from bottommost layer (sent up)
STOP	-	Stop working, UDP layer responds with a STOP_OK
STOP_OK	-	Generated by bottommost layer in response to STOP
MSG	Message	Message traveling up or down the stack
CONNECT	Group name	Connect the channel to the given group. The GMS layer will start a JOIN protocol in response
CONNECT_OK	-	Response generated by GMS layer when JOIN protocol has completed. Sent up the stack.
DISCONNECT	Address	Leave the group. GMS will start LEAVE protocol and send up LEAVE_OK when done
DISCONNECT_OK	-	Generated by GMS layer, sent up the stack
VIEW_CHANGE	View	Generated by GMS, sent up and down the stack when a new view was received (member joined, left group)
GET_LOCAL_ADDRESS	-	Return the local address, response should be generated by bottommost layer. Deprecated.
SET_LOCAL_ADDRESS	Address	Generated by bottommost layer, either in response to GET_LOCAL_ADDRESS or when started (after sending START up the stack)
FLUSH	-	Not yet used
FLUSH_OK	-	Not yet used
SUSPECT	Address	Generated by failure detection layer (e.g. FD). Sent up the stack, handled by the GMS layer. Argument is the suspected member
FIND_INITIAL_MBRS	-	Determine the initial membership. Generated by GMS layer and sent down. Handled by PING layer, which also generates response and sends it up the stack
FIND_INITIAL_MBRS_OK	Vector	Response to FIND_INITIAL_MBRS. Generated by PING, argument is a Vector of PingRsps. Sent up the stack, caught by GMS
MERGE	Vector	Generated by MERGE layer when it detects other members with the same group name, but not in the local view. Sent up the stack. Handled by GMS layer
TMP_VIEW	View	Install a temporary view (not an official one). Use by GMS and other layers to make UDP send out a message to the correct membership. Will in most cases be followed by VIEW_CHANGE
BECOME_SERVER	-	Sent up/down the stack by the GMS layer when a client has successfully joined the group.

Although the events and messages are distinctively different, the term 'message' is used synonymously with 'event' in the following sections, where the flow of events/messages is more important than the difference between them.