next up previous contents
Next: Queue Up: Utility classes Previous: Addresses

   
Messages and Headers

Data is sent between members in the form of messages (JavaGroups.Message ). A message can be sent by a member to a single member, or to all members of the group of which the channel is an endpoint. The structure of a message is shown in fig. 3.1.


  
Figure 3.1: Structure of a message
\begin{figure}
\center{\epsfig{file=/home/bba/JavaGroups/Papers/UsersGuide/figs/Message.eps,width=.4\textwidth} }
\end{figure}

A message is similar to an IP packet and consists of the payload (a byte buffer), the addresses of the sender and receiver, and a number of headers. Any message put on the network can be routed to its destination (receiver address), and replies can be returned to the sender's address.

A message usually does not need to fill in the sender's address when sending a message; this is done automatically by the protocol stack before a message is put on the network. However, there may be cases, when the sender of a message wants to give an address different from its own, so that for example, a response would be returned to some other member.

The destination address (receiver) can be an object, denoting the address of a member, determined e.g. from a message received previously, or it may be null, which means to send the message to all members of the group. A typical multicast message, sending string "Hello" to all members would look like this:

	Message msg=new Message(null, null, new String("Hello").getBytes());

When traveling down a protocol stack, layers may want to add headers with information pertaining to that layer to a message. Headers (class JavaGroups.Header) are wrappers around atomic or more complex data types. Messages have methods to add, remove and peek at headers of a message. Although any type of data types can be tucked into a header, protocols will typically want to create their separate header types as classes, and add them to a message, e.g. as in the example of the fragmentation layer:

        class FragHeader implements Serializable {
            public long    msg_id=0;
            public int     frag_id=0;
            public int     num_frags=0;

            public FragHeader(long msg_id, int frag_id, int num_frags) {
                this.msg_id=msg_id;
                this.frag_id=frag_id;
                this.num_frags=num_frags;
            }

            public String toString() {
                return "[FRAG: msg_id=" + msg_id + ", frag_id=" + frag_id + 
                       ", num_frags=" + num_frags + "]";
            }
        }

The object to be tucked into a header has to be serializable, because headers are part of messages, and messages will need to be serialized to be sent over the network. Since we might want to debug protocol layers later on, it is good practice to provide a toString method, which prints the type and contents of a header.

When a fragmentation layer encounters a Message (traveling down the stack) which size is too big, it would split it into several smaller messages (fragments), and add a header to each fragment which contains a) the original message ID, b) the fragment's ID and the total number of fragments to be expected:

        Message    frag, big_msg;
        FragHeader hdr=new FragHeader(big_msg.GetId(), next_frag_id, tot_frags);
        frag.AddHeader(hdr);
        // pass down the stack

In case the message is not too big, it would just be passed on down to the next layer, without adding any header.

The fragmentation layer on the receiver's side would check whether the top header is of type FragHeader, and if this is the case, remove it and process it (e.g. retrieve all fragments, reassemble them into the original big message, and finally pass the message up the stack:

        FragHeader hdr;
        Object     obj=msg.PeekHeader();  // does not remove header
        if(obj != null && obj instanceof FragHeader) {
            hdr=(FragHeader)msg.RemoveHeader();
            // process header
        }


next up previous contents
Next: Queue Up: Utility classes Previous: Addresses

1999-12-13