<commit_before><?xml version="1.0" encoding="UTF-8"?>
<chapter id="protlist">
    <title>List of Protocols</title>

    <para>For each protocol define:</para>

    <itemizedlist>
        <listitem>
            <para>Properties provided</para>
        </listitem>

        <listitem>
            <para>Required services</para>
        </listitem>

        <listitem>
            <para>Provided services</para>
        </listitem>

        <listitem>
            <para>Behavior</para>
        </listitem>
    </itemizedlist>

    <section>
        <title>Transport</title>

        <section>
            <title>UDP</title>

            <para></para>
        </section>

        <section>
            <title>TCP</title>

            <para></para>
        </section>

        <section>
            <title>TUNNEL</title>

            <para></para>
        </section>

        <section>
            <title>JMS</title>

            <para></para>
        </section>

        <section>
            <title>LOOPBACK</title>

            <para></para>
        </section>
    </section>

    <section>
        <title>Initial membership discovery</title>

        <section>
            <title>PING</title>

            <para></para>
        </section>

        <section>
            <title>TCPPING</title>

            <para></para>
        </section>

        <section>
            <title>TCPGOSSIP</title>

            <para></para>
        </section>

        <section>
            <title>MPING</title>

            <para></para>
        </section>
    </section>

    <section>
        <title>Merging after a network partition</title>

        <section>
            <title>MERGE, MERGE2</title>

            <para></para>
        </section>
    </section>

    <section>


        <title>Failure Detection</title>

        The task of failure detection is to probe members of a group and see whether they are alive. When a member is
        suspected (= deemed dead), then a SUSPECT message is sent to all nodes of the cluster. It is not the task of the
        failure detection layer to exclude a crashed member (this is done by the group membership protocol, GMS), but
        simply to notify everyone that a node in the cluster is suspected of having crashed.

        <section>
            <title>FD</title>

            <para>Failure detection based on heartbeat messages. If reply is not
                received without timeout ms, max_tries times, a member is declared
                suspected, and will be excluded by GMS
            </para>

            <para>Each member send a message containing a "FD" - HEARTBEAT header to
                its neighbor to the right (identified by the ping_dest address). The
                heartbeats are sent by the inner class Monitor. When the neighbor
                receives the HEARTBEAT, it replies with a message containing a "FD" -
                HEARTBEAT_ACK header. The first member watches for "FD" - HEARTBEAT_ACK
                replies from its neigbor. For each received reply, it resets the
                last_ack timestamp (sets it to current time) and num_tries counter (sets
                it to 0). The same Monitor instance that sends heartbeats whatches the
                difference between current time and last_ack. If this difference grows
                over timeout, the Monitor cycles several more times (until max_tries) is
                reached) and then sends a SUSPECT message for the neighbor's address.
                The SUSPECT message is sent down the stack, is addressed to all members,
                and is as a regular message with a FdHeader.SUSPECT header.
            </para>

            <table>
                <title>Properties</title>

                <tgroup cols="2">
                    <colspec align="left"/>

                    <thead>
                        <row>
                            <entry align="center">Name</entry>

                            <entry align="center">Description</entry>
                        </row>
                    </thead>

                    <tbody>
                        <row>
                            <entry>timeout</entry>

                            <entry>Max number of ms to wait for a response, e.g
                                timeout="2500"
                            </entry>
                        </row>

                        <row>
                            <entry>max_tries</entry>

                            <entry>Max number of missed responses until a member is declare
                                suspected., e.g.
                                <code>max_tries="5"</code>
                            </entry>
                        </row>

                        <row>
                            <entry>shun</entry>

                            <entry>Once a member is excluded from the group, and then
                                rejoins (e.g. because it didn't crash, but was just slow, or a
                                router that had crashed came back), it will be excluded
                                (shunned) and then has to rejoin. JGroups allows to configure
                                itself such that shunning leads to automatic rejoins and state
                                transfer (default in JBoss). , e.g.
                                <code>shun="true"</code>
                            </entry>
                        </row>
                    </tbody>
                </tgroup>
            </table>
        </section>


        <section>
            <title>FD_ALL</title>

            <para>Failure detection based on simple heartbeat protocol. Every member periodically multicasts a
                heartbeat.<commit_msg>updated doc<commit_after><?xml version="1.0" encoding="UTF-8"?>
<chapter id="protlist">
    <title>List of Protocols</title>

    <para>For each protocol define:</para>

    <itemizedlist>
        <listitem>
            <para>Properties provided</para>
        </listitem>

        <listitem>
            <para>Required services</para>
        </listitem>

        <listitem>
            <para>Provided services</para>
        </listitem>

        <listitem>
            <para>Behavior</para>
        </listitem>
    </itemizedlist>

    <section>
        <title>Transport</title>

        <section>
            <title>UDP</title>

            <para></para>
        </section>

        <section>
            <title>TCP</title>

            <para></para>
        </section>

        <section>
            <title>TUNNEL</title>

            <para></para>
        </section>

        <section>
            <title>JMS</title>

            <para></para>
        </section>

        <section>
            <title>LOOPBACK</title>

            <para></para>
        </section>
    </section>

    <section>
        <title>Initial membership discovery</title>

        <section>
            <title>PING</title>

            <para></para>
        </section>

        <section>
            <title>TCPPING</title>

            <para></para>
        </section>

        <section>
            <title>TCPGOSSIP</title>

            <para></para>
        </section>

        <section>
            <title>MPING</title>

            <para></para>
        </section>
    </section>

    <section>
        <title>Merging after a network partition</title>

        <section>
            <title>MERGE, MERGE2</title>

            <para></para>
        </section>
    </section>

    <section>


        <title>Failure Detection</title>

        The task of failure detection is to probe members of a group and see whether they are alive. When a member is
        suspected (= deemed dead), then a SUSPECT message is sent to all nodes of the cluster. It is not the task of the
        failure detection layer to exclude a crashed member (this is done by the group membership protocol, GMS), but
        simply to notify everyone that a node in the cluster is suspected of having crashed.

        <section>
            <title>FD</title>

            <para>Failure detection based on heartbeat messages. If reply is not
                received without timeout ms, max_tries times, a member is declared
                suspected, and will be excluded by GMS
            </para>

            <para>Each member send a message containing a "FD" - HEARTBEAT header to
                its neighbor to the right (identified by the ping_dest address). The
                heartbeats are sent by the inner class Monitor. When the neighbor
                receives the HEARTBEAT, it replies with a message containing a "FD" -
                HEARTBEAT_ACK header. The first member watches for "FD" - HEARTBEAT_ACK
                replies from its neigbor. For each received reply, it resets the
                last_ack timestamp (sets it to current time) and num_tries counter (sets
                it to 0). The same Monitor instance that sends heartbeats whatches the
                difference between current time and last_ack. If this difference grows
                over timeout, the Monitor cycles several more times (until max_tries) is
                reached) and then sends a SUSPECT message for the neighbor's address.
                The SUSPECT message is sent down the stack, is addressed to all members,
                and is as a regular message with a FdHeader.SUSPECT header.
            </para>

            <table>
                <title>Properties</title>

                <tgroup cols="2">
                    <colspec align="left"/>

                    <thead>
                        <row>
                            <entry align="center">Name</entry>

                            <entry align="center">Description</entry>
                        </row>
                    </thead>

                    <tbody>
                        <row>
                            <entry>timeout</entry>

                            <entry>Max number of ms to wait for a response, e.g
                                timeout="2500"
                            </entry>
                        </row>

                        <row>
                            <entry>max_tries</entry>

                            <entry>Max number of missed responses until a member is declare
                                suspected., e.g.
                                <code>max_tries="5"</code>
                            </entry>
                        </row>

                        <row>
                            <entry>shun</entry>

                            <entry>Once a member is excluded from the group, and then
                                rejoins (e.g. because it didn't crash, but was just slow, or a
                                router that had crashed came back), it will be excluded
                                (shunned) and then has to rejoin. JGroups allows to configure
                                itself such that shunning leads to automatic rejoins and state
                                transfer (default in JBoss). , e.g.
                                <code>shun="true"</code>. Automatic rejoins can be enabled by setting channel option
                                AUTO_RECONNECT to true: channel.setOpt(Channel.AUTO_RECONNECT, Boolean.TRUE). Same
                                for automatically fetching the state after automatic reconnection:
                                channel.setOpt(Channel.AUTO_GETSTATE, Boolean.TRUE).
                            </entry>
                        </row>
                    </tbody>
                </tgroup>
            </table>
        </section>


        <section>
            <title>FD_ALL</title>

            <para>Failure detection based on simple heartbeat protocol. Every member periodically multicasts a
                heartbeat.
{'fraction_non_alphanumeric': 0.0832842105263158, 'fraction_numerical': 0.0018526315789473683, 'mean_word_length': 1.2707456978967495, 'pattern_counts': {'":': 0, '<': 303, '<?xml version=': 2, '>': 303, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 2}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 1, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '5306386', 'n_tokens_mistral': 2966, 'n_tokens_neox': 2767, 'n_words': 957}