diff options
| author | Lorry Tar Creator <lorry-tar-importer@baserock.org> | 2015-02-17 17:25:57 +0000 |
|---|---|---|
| committer | <> | 2015-03-17 16:26:24 +0000 |
| commit | 780b92ada9afcf1d58085a83a0b9e6bc982203d1 (patch) | |
| tree | 598f8b9fa431b228d29897e798de4ac0c1d3d970 /docs/programmer_reference/rep_ex_comm.html | |
| parent | 7a2660ba9cc2dc03a69ddfcfd95369395cc87444 (diff) | |
| download | berkeleydb-master.tar.gz | |
Diffstat (limited to 'docs/programmer_reference/rep_ex_comm.html')
| -rw-r--r-- | docs/programmer_reference/rep_ex_comm.html | 170 |
1 files changed, 97 insertions, 73 deletions
diff --git a/docs/programmer_reference/rep_ex_comm.html b/docs/programmer_reference/rep_ex_comm.html index ac219a2f..3be89b65 100644 --- a/docs/programmer_reference/rep_ex_comm.html +++ b/docs/programmer_reference/rep_ex_comm.html @@ -14,7 +14,7 @@ <body> <div xmlns="" class="navheader"> <div class="libver"> - <p>Library Version 11.2.5.3</p> + <p>Library Version 12.1.6.1</p> </div> <table width="100%" summary="Navigation header"> <tr> @@ -22,9 +22,7 @@ </tr> <tr> <td width="20%" align="left"><a accesskey="p" href="rep_ex.html">Prev</a> </td> - <th width="60%" align="center">Chapter 12. - Berkeley DB Replication - </th> + <th width="60%" align="center">Chapter 12. Berkeley DB Replication </th> <td width="20%" align="right"> <a accesskey="n" href="rep_ex_rq.html">Next</a></td> </tr> </table> @@ -39,74 +37,99 @@ </div> </div> <p> -Base API applications must implement a -communication infrastructure. The communication infrastructure -consists of three parts: a way to map environment IDs to particular -sites, the functions to send and receive messages, and the application -architecture that supports the particular communication infrastructure -used (for example, individual threads per communicating site, a shared -message handler for all sites, a hybrid solution). The communication -infrastructure for ex_rep_base is implemented in the file -<code class="filename">ex_rep/base/rep_net.c</code>, and each part of that infrastructure -is described as follows.</p> - <p>Ex_rep_base maintains a table of environment ID to TCP/IP port -mappings. A pointer to this table is stored in a structure pointed to -by the app_private field of the <a href="../api_reference/C/env.html" class="olink">DB_ENV</a> object so it can be -accessed by any function that has the database environment handle. -The table is represented by a machtab_t structure which contains a -reference to a linked list of member_t's, both of which are defined in -<code class="filename">ex_rep/base/rep_net.c</code>. Each member_t contains the host and -port identification, the environment ID, and a file descriptor.</p> - <p>This design is particular to this application and communication -infrastructure, but provides an indication of the sort of functionality -that is needed to maintain the application-specific state for a -TCP/IP-based infrastructure. The goal of the table and its interfaces -is threefold: First, it must guarantee that given an environment ID, -the send function can send a message to the appropriate place. Second, -when given the special environment ID <a href="../api_reference/C/reptransport.html#transport_DB_EID_BROADCAST" class="olink">DB_EID_BROADCAST</a>, the send -function can send messages to all the machines in the group. Third, -upon receipt of an incoming message, the receive function can correctly -identify the sender and pass the appropriate environment ID to the -<a href="../api_reference/C/repmessage.html" class="olink">DB_ENV->rep_process_message()</a> method.</p> - <p>Mapping a particular environment ID to a specific port is accomplished -by looping through the linked list until the desired environment ID is -found. Broadcast communication is implemented by looping through the -linked list and sending to each member found. Since each port -communicates with only a single other environment, receipt of a message -on a particular port precisely identifies the sender.</p> - <p>This is implemented in the quote_send, quote_send_broadcast and -quote_send_one functions, which can be found in -<code class="filename">ex_rep/base/rep_net.c</code>.</p> - <p>The example provided is merely one way to satisfy these requirements, -and there are alternative implementations as well. For instance, -instead of associating separate socket connections with each remote -environment, an application might instead label each message with a -sender identifier; instead of looping through a table and sending a -copy of a message to each member of the replication group, the -application could send a single message using a broadcast protocol.</p> - <p>The quote_send function is passed as the callback to -<a href="../api_reference/C/reptransport.html" class="olink">DB_ENV->rep_set_transport()</a>; Berkeley DB automatically sends messages as needed -for replication. The receive function is a mirror to the quote_send_one -function. It is not a callback function (the application is responsible -for collecting messages and calling <a href="../api_reference/C/repmessage.html" class="olink">DB_ENV->rep_process_message()</a> on them as is -convenient). In the sample application, all messages transmitted are -Berkeley DB messages that get handled by <a href="../api_reference/C/repmessage.html" class="olink">DB_ENV->rep_process_message()</a>, however, this -is not always going to be the case. The application may want to pass -its own messages across the same channels, distinguish between its own -messages and those of Berkeley DB, and then pass only the Berkeley DB ones to -<a href="../api_reference/C/repmessage.html" class="olink">DB_ENV->rep_process_message()</a>.</p> - <p>The final component of the communication infrastructure is the process -model used to communicate with all the sites in the replication group. -Each site creates a thread of control that listens on its designated -socket (as specified by the <span class="bold"><strong>-l</strong></span> command line argument) and -then creates a new channel for each site that contacts it. In addition, -each site explicitly connects to the sites specified in the -<span class="bold"><strong>-r</strong></span> and <span class="bold"><strong>-R</strong></span> -command line arguments. This is a fairly standard TCP/IP -process architecture and is implemented by the connect_thread, -connect_all and connect_site functions -in <code class="filename">ex_rep/base/rep_msg.c</code> and supporting functions -in <code class="filename">ex_rep/base/rep_net.c</code>.</p> + Base API applications must implement a communication + infrastructure. The communication infrastructure consists of + three parts: a way to map environment IDs to particular sites, + the functions to send and receive messages, and the + application architecture that supports the particular + communication infrastructure used (for example, individual + threads per communicating site, a shared message handler for + all sites, a hybrid solution). The communication + infrastructure for ex_rep_base is implemented in the file + <code class="filename">ex_rep/base/rep_net.c</code>, and each part + of that infrastructure is described as follows. + </p> + <p> + Ex_rep_base maintains a table of environment ID to TCP/IP + port mappings. A pointer to this table is stored in a + structure pointed to by the app_private field of the <a href="../api_reference/C/env.html" class="olink">DB_ENV</a> + object so it can be accessed by any function that has the + database environment handle. The table is represented by a + machtab_t structure which contains a reference to a linked + list of member_t's, both of which are defined in + <code class="filename">ex_rep/base/rep_net.c</code>. Each member_t + contains the host and port identification, the environment ID, + and a file descriptor. + </p> + <p> + This design is particular to this application and + communication infrastructure, but provides an indication of + the sort of functionality that is needed to maintain the + application-specific state for a TCP/IP-based infrastructure. + The goal of the table and its interfaces is threefold: First, + it must guarantee that given an environment ID, the send + function can send a message to the appropriate place. Second, + when given the special environment ID <a href="../api_reference/C/reptransport.html#transport_DB_EID_BROADCAST" class="olink">DB_EID_BROADCAST</a>, the + send function can send messages to all the machines in the + group. Third, upon receipt of an incoming message, the receive + function can correctly identify the sender and pass the + appropriate environment ID to the <a href="../api_reference/C/repmessage.html" class="olink">DB_ENV->rep_process_message()</a> method. + </p> + <p> + Mapping a particular environment ID to a specific port is + accomplished by looping through the linked list until the + desired environment ID is found. Broadcast communication is + implemented by looping through the linked list and sending to + each member found. Since each port communicates with only a + single other environment, receipt of a message on a particular + port precisely identifies the sender. + </p> + <p> + This is implemented in the quote_send, quote_send_broadcast + and quote_send_one functions, which can be found in + <code class="filename">ex_rep/base/rep_net.c</code>. + </p> + <p> + The example provided is merely one way to satisfy these + requirements, and there are alternative implementations as + well. For instance, instead of associating separate socket + connections with each remote environment, an application might + instead label each message with a sender identifier; instead + of looping through a table and sending a copy of a message to + each member of the replication group, the application could + send a single message using a broadcast protocol. + </p> + <p> + The quote_send function is passed as the callback to + <a href="../api_reference/C/reptransport.html" class="olink">DB_ENV->rep_set_transport()</a>; Berkeley DB automatically sends messages as + needed for replication. The receive function is a mirror to + the quote_send_one function. It is not a callback function + (the application is responsible for collecting messages and + calling <a href="../api_reference/C/repmessage.html" class="olink">DB_ENV->rep_process_message()</a> on them as is convenient). In the sample + application, all messages transmitted are Berkeley DB messages + that get handled by <a href="../api_reference/C/repmessage.html" class="olink">DB_ENV->rep_process_message()</a>, however, this is not always + going to be the case. The application may want to pass its own + messages across the same channels, distinguish between its own + messages and those of Berkeley DB, and then pass only the + Berkeley DB ones to <a href="../api_reference/C/repmessage.html" class="olink">DB_ENV->rep_process_message()</a>. + </p> + <p> + The final component of the communication infrastructure is + the process model used to communicate with all the sites in + the replication group. Each site creates a thread of control + that listens on its designated socket (as specified by the + <span class="bold"><strong>-l</strong></span> command line argument) + and then creates a new channel for each site that contacts it. + In addition, each site explicitly connects to the sites + specified in the <span class="bold"><strong>-r</strong></span> and + <span class="bold"><strong>-R</strong></span> command line + arguments. This is a fairly standard TCP/IP process + architecture and is implemented by the connect_thread, + connect_all and connect_site functions in + <code class="filename">ex_rep/base/rep_msg.c</code> and supporting + functions in + <code class="filename">ex_rep/base/rep_net.c</code>. + </p> </div> <div class="navfooter"> <hr /> @@ -123,7 +146,8 @@ in <code class="filename">ex_rep/base/rep_net.c</code>.</p> <td width="20%" align="center"> <a accesskey="h" href="index.html">Home</a> </td> - <td width="40%" align="right" valign="top"> Ex_rep_base: putting it all together</td> + <td width="40%" align="right" valign="top"> Ex_rep_base: putting it all + together</td> </tr> </table> </div> |