JGroups Protocol PING: Difference between revisions
| (5 intermediate revisions by the same user not shown) | |||
| Line 30: | Line 30: | ||
=Periodic GET_MBRS_REQ Requests= | =Periodic GET_MBRS_REQ Requests= | ||
The super- | The super-class Discovery protocol is in charge with sending GET_MBRS_REQ (get members) requests upon receiving a FIND_ALL_VIEWS , FIND_INITIAL_MBRS, etc. event. The "find" events are sent either by the [[JGroups Protocol GMS|GMS]] protocol, when initializing, or periodically by the FindSubgroupsTask of the [[JGroups Protocol MERGE2|MERGE2]] protocol. | ||
The discovery requests are generated by the PingSenderTask, in the form of OOB messages with PingHeader.GET_MBRS_REQ headers. PingSenderTask sends these messages in a delayed loop. The delay between requests is | The discovery requests are generated by the PingSenderTask, in the form of OOB messages with PingHeader.GET_MBRS_REQ headers. PingSenderTask sends these messages in a delayed loop. The delay between requests is <tt>timeout /num_ping_requests</tt> where <tt>timeout</tt> and <tt>num_ping_requests</tt> are configuration parameters described below. Normally that should be about 1.5 sec (1,500 ms). | ||
The loop is interrupted either after a 'timeout' milliseconds (which means that all 'num_ping_requests' discovery requests have been sent), or after the first valid response - which allows determining who the coordinator is - is received. <font color=red>Further clarifications needed as to how 'num_initial_members' works.</font> | The loop is interrupted either after a 'timeout' milliseconds (which means that all 'num_ping_requests' discovery requests have been sent), or after the first valid response - which allows determining who the coordinator is - is received. <font color=red>Further clarifications needed as to how 'num_initial_members' works.</font> | ||
| Line 38: | Line 38: | ||
A new PingSenderTask - and the loop - will be started again when a new GET_MBRS_REQ message needs to be sent. | A new PingSenderTask - and the loop - will be started again when a new GET_MBRS_REQ message needs to be sent. | ||
The result of the GET_MBRS_REQ process is a list of ping responses (see <tt>PingData</tt>). | |||
==Stack Boot Time Factor== | |||
The whole stack is waiting while the first discovery loop is running, setting the 'timeout' to a smaller value can reduce the stack boot time. | The whole stack is waiting while the first discovery loop is running, setting the 'timeout' to a smaller value can reduce the stack boot time. | ||
=Configuration= | |||
==timeout== | |||
The timeout to wait for the initial members. Default is 3000 ms. | The timeout to wait for the initial members. Default is 3000 ms. | ||
==num_initial_members== | |||
<font color=red> | <font color=red> | ||
TODO | |||
</font> | </font> | ||
==num_ping_requests== | |||
Number of discovery requests to be sent distributed over <tt>timeout</tt>. Default is 2. | |||
=Filtering Out= | |||
If you want to filter these messages out, the header id is <tt>6</tt>. | |||
Latest revision as of 06:27, 3 March 2016
External
- JGroups Manual http://www.jgroups.org/manual/html/protlist.html#PING
- JGroups Wiki http://community.jboss.org/wiki/JGroupsPING
Internal
TODO
- Next time I dive into this, come up with a full explanation for 'num_initial_members' below.
Overview
PING performs the initial (dirty) discovery of members, by multicasting PING request to an IP multicast address. The PING request is a Message with a PingHeader.GET_MBRS_REQ header. Each member replies with a (C, A) packet where C = coordinator address and A its own address. After a set number of milliseconds ('timeout') or replies ('num_initial_members'), the joiner determines the coordinator from responses, and sends a JOIN to it. The JOIN request is handled by the GMS layer. If nobody responds, the joiner assumes it's the first member of a group.
Configuration
<PING timeout="2000" num_initial_members="3"/>
Difference between PING and MPING
MPING, unlike PING, uses its own IP multicast socket to send discovery requests. PING simply sends a discover event down the stack to be sent by the underlying transport protocol.
Periodic GET_MBRS_REQ Requests
The super-class Discovery protocol is in charge with sending GET_MBRS_REQ (get members) requests upon receiving a FIND_ALL_VIEWS , FIND_INITIAL_MBRS, etc. event. The "find" events are sent either by the GMS protocol, when initializing, or periodically by the FindSubgroupsTask of the MERGE2 protocol.
The discovery requests are generated by the PingSenderTask, in the form of OOB messages with PingHeader.GET_MBRS_REQ headers. PingSenderTask sends these messages in a delayed loop. The delay between requests is timeout /num_ping_requests where timeout and num_ping_requests are configuration parameters described below. Normally that should be about 1.5 sec (1,500 ms).
The loop is interrupted either after a 'timeout' milliseconds (which means that all 'num_ping_requests' discovery requests have been sent), or after the first valid response - which allows determining who the coordinator is - is received. Further clarifications needed as to how 'num_initial_members' works.
A new PingSenderTask - and the loop - will be started again when a new GET_MBRS_REQ message needs to be sent.
The result of the GET_MBRS_REQ process is a list of ping responses (see PingData).
Stack Boot Time Factor
The whole stack is waiting while the first discovery loop is running, setting the 'timeout' to a smaller value can reduce the stack boot time.
Configuration
timeout
The timeout to wait for the initial members. Default is 3000 ms.
num_initial_members
TODO
num_ping_requests
Number of discovery requests to be sent distributed over timeout. Default is 2.
Filtering Out
If you want to filter these messages out, the header id is 6.