JGroups的协议栈
组通信领域，JGroups作为可靠的多播通信工具集享有盛名。JGroups的一大特点就是其灵活的协议栈 Protocol stack, 灵活固然好，有时不明就里，胡乱搭配，反而不妙。
所以，要搞清楚协议的应用场景和参数配置意义，举例如下
<config>
<UDP
mcast_port="${jgroups.udp.mcast_port:45588}"
tos="8"
ucast_recv_buf_size="20M"
ucast_send_buf_size="640K"
mcast_recv_buf_size="25M"
mcast_send_buf_size="640K"
loopback="true"
discard_incompatible_packets="true"
max_bundle_size="64K"
max_bundle_timeout="30"
ip_ttl="${jgroups.udp.ip_ttl:2}"
enable_bundling="true"
enable_diagnostics="true"
thread_naming_pattern="cl"
timer.num_threads="4"
thread_pool.enabled="true"
thread_pool.min_threads="2"
thread_pool.max_threads="8"
thread_pool.keep_alive_time="5000"
thread_pool.queue_enabled="true"
thread_pool.queue_max_size="10000"
thread_pool.rejection_policy="discard"
oob_thread_pool.enabled="true"
oob_thread_pool.min_threads="1"
oob_thread_pool.max_threads="8"
oob_thread_pool.keep_alive_time="5000"
oob_thread_pool.queue_enabled="false"
oob_thread_pool.queue_max_size="100"
oob_thread_pool.rejection_policy="Run"/>
<PING timeout="2000"
num_initial_members="3"/>
<MERGE2 max_interval="30000"
min_interval="10000"/>
<FD_SOCK/>
<FD_ALL/>
<VERIFY_SUSPECT timeout="1500" />
<BARRIER />
<pbcast.NAKACK use_stats_for_retransmission="false"
exponential_backoff="0"
use_mcast_xmit="true" gc_lag="0"
retransmit_timeout="300,600,1200"
discard_delivered_msgs="true"/>
<UNICAST timeout="300,600,1200"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
max_bytes="1M"/>
<pbcast.GMS print_local_addr="false" join_timeout="3000"
view_bundling="true"/>
<FC max_credits="500K"
min_threshold="0.20"/>
<FRAG2 frag_size="60K" />
<pbcast.STREAMING_STATE_TRANSFER />
<!--pbcast.STATE_TRANSFER /-->
<!-- pbcast.FLUSH /-->
</config>
1. UDP 协议，学过计算机网络的人都知道UDP是传输层的基本协议，特点就是快但不一定可靠， 这里是用基于UDP的多播multicast协议来发送消息的， 也可以改成其他传输协议，如 tcp, tcp_nio, tunnel
This is the transport protocol. It uses IP multicasting to send messages to the entire cluster, or individual nodes. Other transports include TCP, TCP_NIO and TUNNEL.
2. PING协议， 用缺省的IP多播来发现最初的成员， 类似于操作系统的 ping 命令，一旦ping通，则一个单播join请求将被发送至它以加入当前的 group 或者叫做cluster
Uses IP multicast (by default) to find initial members. Once found, the current coordinator can be determined and a unicast JOIN request will be sent to it in order to join the cluster.
3. MERGE2, 用来合并子组，或在一个子组分离时去除子组
Will merge subgroups back into one group, kicks in after a cluster partition.
4. FD_SOCK 基于socket 的错误检测协议 (在成员之间形成的一个环)，当某个成员失败时会生成通知
Failure detection based on sockets (in a ring form between members). Generates notification if a member fails
5. FD 基于心跳 heartbeat 和 你还活着 are-you-live 消息的错误检测协议 (在成员之间形成的一个环)，当某个成员失败时会生成通知
Failure detection based on heartbeats and are-you-alive messages (in a ring form between members). Generates notification if a member fails
6. VERIFY_SUSPECT 重复检测一个挂起的成员 是否 已经死掉了， 否则以下协议产生的消息将被丢弃
Double-checks whether a suspected member is really dead, otherwise the suspicion generated from protocol below is discarded
7. pbcast.NAKACK 确保消息的可靠和 FIFO 顺序 , 消息可靠性保证了一个消息会被收到，否则接收者会要求重传，FIFO保证了从发送者发过来的所有消息会以相同顺序到达接收方
Ensures (a) message reliability and (b) FIFO. Message reliability guarantees that a message will be received. If not, the receiver(s) will request retransmission. FIFO guarantees that all messages from sender P will be received in the order P sent them
8. UNICAST 与NAKACK差不多，只不过它不是多播，而是单播的
Same as NAKACK for unicast messages: messages from sender P will not be lost (retransmission if necessary) and will be in FIFO order (conceptually the same as TCP in TCP/IP)
9. pbcast.STABLE 将已被所有成员收到的消息删除，即分布式垃圾回收
Deletes messages that have been seen by all members (distributed message garbage collection)
10. pbcast.GMS 成员协议，负责成员的 加入/离开 并更新新的成员视图
Membership protocol. Responsible for joining/leaving members and installing new views.
11. FRAG2 将巨大的消息打碎分割成若干个小的发送，并在接收端重新组装回去，适用于多播和单播协议
Fragments large messages into smaller ones and reassembles them back at the receiver side. For both multicast and unicast messages
12. STATE_TRANSFER 状态传输，确保状态可以正确地从一个成员传输到其他的成员
Ensures that state is correctly transferred from an existing member (usually the coordinator) to a new member
转自
http://blog.csdn.net/fanyamin/article/details/6217032
所以，要搞清楚协议的应用场景和参数配置意义，举例如下
<config>
<UDP
mcast_port="${jgroups.udp.mcast_port:45588}"
tos="8"
ucast_recv_buf_size="20M"
ucast_send_buf_size="640K"
mcast_recv_buf_size="25M"
mcast_send_buf_size="640K"
loopback="true"
discard_incompatible_packets="true"
max_bundle_size="64K"
max_bundle_timeout="30"
ip_ttl="${jgroups.udp.ip_ttl:2}"
enable_bundling="true"
enable_diagnostics="true"
thread_naming_pattern="cl"
timer.num_threads="4"
thread_pool.enabled="true"
thread_pool.min_threads="2"
thread_pool.max_threads="8"
thread_pool.keep_alive_time="5000"
thread_pool.queue_enabled="true"
thread_pool.queue_max_size="10000"
thread_pool.rejection_policy="discard"
oob_thread_pool.enabled="true"
oob_thread_pool.min_threads="1"
oob_thread_pool.max_threads="8"
oob_thread_pool.keep_alive_time="5000"
oob_thread_pool.queue_enabled="false"
oob_thread_pool.queue_max_size="100"
oob_thread_pool.rejection_policy="Run"/>
<PING timeout="2000"
num_initial_members="3"/>
<MERGE2 max_interval="30000"
min_interval="10000"/>
<FD_SOCK/>
<FD_ALL/>
<VERIFY_SUSPECT timeout="1500" />
<BARRIER />
<pbcast.NAKACK use_stats_for_retransmission="false"
exponential_backoff="0"
use_mcast_xmit="true" gc_lag="0"
retransmit_timeout="300,600,1200"
discard_delivered_msgs="true"/>
<UNICAST timeout="300,600,1200"/>
<pbcast.STABLE stability_delay="1000" desired_avg_gossip="50000"
max_bytes="1M"/>
<pbcast.GMS print_local_addr="false" join_timeout="3000"
view_bundling="true"/>
<FC max_credits="500K"
min_threshold="0.20"/>
<FRAG2 frag_size="60K" />
<pbcast.STREAMING_STATE_TRANSFER />
<!--pbcast.STATE_TRANSFER /-->
<!-- pbcast.FLUSH /-->
</config>
1. UDP 协议，学过计算机网络的人都知道UDP是传输层的基本协议，特点就是快但不一定可靠， 这里是用基于UDP的多播multicast协议来发送消息的， 也可以改成其他传输协议，如 tcp, tcp_nio, tunnel
This is the transport protocol. It uses IP multicasting to send messages to the entire cluster, or individual nodes. Other transports include TCP, TCP_NIO and TUNNEL.
2. PING协议， 用缺省的IP多播来发现最初的成员， 类似于操作系统的 ping 命令，一旦ping通，则一个单播join请求将被发送至它以加入当前的 group 或者叫做cluster
Uses IP multicast (by default) to find initial members. Once found, the current coordinator can be determined and a unicast JOIN request will be sent to it in order to join the cluster.
3. MERGE2, 用来合并子组，或在一个子组分离时去除子组
Will merge subgroups back into one group, kicks in after a cluster partition.
4. FD_SOCK 基于socket 的错误检测协议 (在成员之间形成的一个环)，当某个成员失败时会生成通知
Failure detection based on sockets (in a ring form between members). Generates notification if a member fails
5. FD 基于心跳 heartbeat 和 你还活着 are-you-live 消息的错误检测协议 (在成员之间形成的一个环)，当某个成员失败时会生成通知
Failure detection based on heartbeats and are-you-alive messages (in a ring form between members). Generates notification if a member fails
6. VERIFY_SUSPECT 重复检测一个挂起的成员 是否 已经死掉了， 否则以下协议产生的消息将被丢弃
Double-checks whether a suspected member is really dead, otherwise the suspicion generated from protocol below is discarded
7. pbcast.NAKACK 确保消息的可靠和 FIFO 顺序 , 消息可靠性保证了一个消息会被收到，否则接收者会要求重传，FIFO保证了从发送者发过来的所有消息会以相同顺序到达接收方
Ensures (a) message reliability and (b) FIFO. Message reliability guarantees that a message will be received. If not, the receiver(s) will request retransmission. FIFO guarantees that all messages from sender P will be received in the order P sent them
8. UNICAST 与NAKACK差不多，只不过它不是多播，而是单播的
Same as NAKACK for unicast messages: messages from sender P will not be lost (retransmission if necessary) and will be in FIFO order (conceptually the same as TCP in TCP/IP)
9. pbcast.STABLE 将已被所有成员收到的消息删除，即分布式垃圾回收
Deletes messages that have been seen by all members (distributed message garbage collection)
10. pbcast.GMS 成员协议，负责成员的 加入/离开 并更新新的成员视图
Membership protocol. Responsible for joining/leaving members and installing new views.
11. FRAG2 将巨大的消息打碎分割成若干个小的发送，并在接收端重新组装回去，适用于多播和单播协议
Fragments large messages into smaller ones and reassembles them back at the receiver side. For both multicast and unicast messages
12. STATE_TRANSFER 状态传输，确保状态可以正确地从一个成员传输到其他的成员
Ensures that state is correctly transferred from an existing member (usually the coordinator) to a new member
转自
http://blog.csdn.net/fanyamin/article/details/6217032