組通信之jgroups篇----Adress,View,Message,Event

3.3. Address
Each member of a group has an address, which uniquely identifies the member. The interface for such an address is Address, which requires concrete implementations to provide methods for comparison and sorting of addresses, and for determination whether the address is a multicast address. JGroups addresses have to implement the following interface:

            public interface Address extends Externalizable, Comparable, Cloneable {
                boolean isMulticastAddress();
                int compareTo(Object o) throws ClassCastException;
                boolean equals(Object obj);
                int hashCode();
                String toString();
            }
Please never use implementations of Address directly; Address should always be used as an opaque identifier of a cluster node !

Actual implementations of addresses are often generated by the bottommost protocol layer (e.g. UDP or TCP). This allows for all possible sorts of addresses to be used with JGroups, e.g. ATM.

In JChannel, it is the IP address of the host on which the stack is running and the port on which the stack is receiving incoming messages; it is represented by the concrete class org.jgroups.stack.IpAddress. Instances of this class are only used within the JChannel protocol stack; users of a channel see addresses (of any kind) only as Addresses. Since an address uniquely identifies a channel, and therefore a group member, it can be used to send messages to that group member, e.g. in Messages (see next section).

In 2.8, the default implementation of Address was changed from IpAddress to org.jgroups.util.UUID.

組內每個成員都有一個地址,它唯一標誌該成員.其接口即爲Address.它需要具體實現如下的一些方法.

不要直接使用Adress的實現(對象),應將Adress當作集羣節點不透明標誌符使用.

地址的具體實現一般在最底層協議生成,它允許JGroups使用所有可能的地址類型.

在JChannel層,使用主機的IP地址,它由org.jgroups.stack.IpAddress類實現.此類的對象只在協議棧中使用,用戶通過channel得到的仍然是Adress對象,Adress唯一代表了channel,代表了組成員.

在2.8版本中,Adress的默認實現已由IpAddress轉變爲org.jgroups.util.UUID.

 

3.5. View
A View ( View ) is a list of the current members of a group. It consists of a ViewId , which uniquely identifies the view(see below), and a list of members. Views are set in a channel automatically by the underlying protocol stack whenever a new member joins or an existing one leaves (or crashes). All members of a group see the same sequence of views.

Note that there is a comparison function which orders all the members of a group in the same way. Usually, the first member of the list is the coordinator (the one who emits new views). Thus, whenever the membership changes, every member can determine the coordinator easily and without having to contact other members.

The code below shows how to send a (unicast) message to the first member of a view (error checking code omitted):

            View view=channel.getView();
            Address first=view.getMembers().first();
            Message msg=new Message(first, null, "Hello world");
            channel.send(msg);
Whenever an application is notified that a new view has been installed (e.g. by Receiver.viewAccepted(), the view is already set in the channel. For example, calling Channel.getView() in a viewAccepted() callback would return the same view (or possibly the next one in case there has already been a new view !).

3.5.1. ViewId
The ViewId is used to uniquely number views. It consists of the address of the view creator and a sequence number. ViewIds can be compared for equality and put in a hashtable as they implement equals() and hashCode() methods.

3.5.2. MergeView
Whenever a group splits into subgroups, e.g. due to a network partition, and later the subgroups merge back together, a MergeView instead of a View will be received by the application. The MergeView class is a subclass of View and contains as additional instance variable the list of views that were merged. As an example if the group denoted by view V1:(p,q,r,s,t) split into subgroups V2:(p,q,r) and V2:(s,t) , the merged view might be V3:(p,q,r,s,t) . In this case the MergeView would contains a list of 2 views: V2:(p,q,r) and V2:(s,t) .

view指的是某個組的當前所有成員列表,它包含有viewID,它唯一標誌組.還包含成員列表.當有成員加入,退出,異常時,channel中的view會被底層協議棧自動賦值.每個成員的view是一致有序的.

有比較函數可以將組內成員以相同的方式排序.一般的,第一個成員是主,不管組成員關係什麼時候發生變化,每個成員都不需要跟其他成員通信就能決定出新的主.

下面的代碼顯示瞭如何單播發送消息到view中的第一個成員.

無論何時應用程序被通知有新的view產生,channel中的view都已經被設置.

3.5.1. ViewId

包含一個序列號和該view的創建者,viewId可以被比較

3.5.2. MergeView

當一個組被切分成幾個子組,如網絡分區,隨後,多個子組又重新組合到一起.應用程序會收到MergeView而不是View.MergeView是View的子類,且包含要被組合的視圖列表.舉例:如果某個組的視圖V1:(p,q,r,s,t) 被分成兩個組 V2:(p,q,r) 和 V2:(s,t),組合後的試圖將會是V3:(p,q,r,s,t),

MergeView將包含有一個列表,該列表含有V2:(p,q,r) 和 V2:(s,t).

 

3.4. Message

Data is sent between members in the form of messages ( org.jgroups.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.

A message contains 5 fields:

Destination address

The address of the receiver. If null , the message will be sent to all current group members

Source address

The address of the sender. Can be left null , and will be filled in by the transport protocol (e.g. UDP) before the message is put on the network

Flags

This is one byte used for flags. The currently recognized flags are OOB, LOW_PRIO and HIGH_PRIO. See the discussion on the concurrent stack for OOB.

Payload

The actual data (as a byte buffer). The Message class contains convenience methods to set a serializable object and to retrieve it again, using serialization to convert the object to/from a byte buffer.

Headers

A list of headers that can be attached to a message. Anything that should not be in the payload can be attached to a message as a header. Methods putHeader() , getHeader() and removeHeader() of Message can be used to manipulate headers.

A message is similar to an IP packet and consists of the payload (a byte buffer) and the addresses of the sender and receiver (as Addresses). 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 should be returned to some other member.

The destination address (receiver) can be an Address, denoting the address of a member, determined e.g. from a message received previously, or it can be null , which means that the message will be sent 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, "Hello".getBytes());

            channel.send(msg);

數據以消息的形式在成員間發送.消息可以發送到一個成員或發送到當前組內所有成員.

1個消息包含5個部分:

目的地址:接收端地址,如果爲空,則發送到組內所有成員.

源端地址:發送端地址,可以爲空,將在傳輸層填充地址,然後將消息發送到網絡上.

標誌位:1個字節的標誌位,現在能支持的有 OOB, LOW_PRIO和HIGH_PRIO.

有效負載:真實的數據.消息類有方便的方法去設置一個流式對象或得到一個流式對象.

頭:頭隊列可以加到消息內,所有不在有效負載內的信息都可以加到頭中.

消息類似於一個IP包,包含有效負載,發送端地址和接收端地址,網絡上的消息可以到達它的目的端,同時迴應消息也能返回到發送端.

消息通常不需要填充發送端地址,這將自動在協議棧中處理,然後消息纔會發送到網絡上.但如果想給此消息設置一個非本地的地址,那回應消息則發到另一個成員上了.

接受端地址一般可以爲一個Address,表示一個成員的地址(該地址通常由上次接收到的消息所決定),也可以爲空,表示此消息發送到組內所有成員.一個典型的組播消息,發送"你好"到所有成員如下.

 

 

1.4. Header

A header is a custom bit of information that can be added to each message. JGroups uses headers extensively, for example to add sequence numbers to each message (NAKACK and UNICAST), so that those messages can be de-

 

報文頭是約定的一些少量信息,可以加在每個消息上.JGroups廣泛使用報文頭,比如增加序列號到消息裏,可以保證消息傳遞的有序性.

 

1.5. Event

Events are means by which JGroups protcols can talk to each other. Contrary to Messages, which travel over the network between group members, events only travel up and down the stack.

 

事件保證JGroups各協議可以互相交流.不同於消息,它在網絡中組成員中傳遞,而事件只在協議棧中上下傳輸.

 

發佈了38 篇原創文章 · 獲贊 10 · 訪問量 17萬+
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章