Library Version 11.2.5.3

Library Version 12.1.6.1

@@ -22,9 +22,7 @@ - +

Prev	Chapter 12. - Berkeley DB Replication -	Chapter 12. Berkeley DB Replication	Next

@@ -39,74 +37,99 @@

-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 -ex_rep/base/rep_net.c, and each part of that infrastructure -is described as follows.

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 DB_ENV 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 -ex_rep/base/rep_net.c. Each member_t contains the host and -port identification, the environment ID, and a file descriptor.

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 DB_EID_BROADCAST, 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 -DB_ENV->rep_process_message() method.

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.

This is implemented in the quote_send, quote_send_broadcast and -quote_send_one functions, which can be found in -ex_rep/base/rep_net.c.

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.

The quote_send function is passed as the callback to -DB_ENV->rep_set_transport(); 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 DB_ENV->rep_process_message() on them as is -convenient). In the sample application, all messages transmitted are -Berkeley DB messages that get handled by DB_ENV->rep_process_message(), 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 -DB_ENV->rep_process_message().

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 -l 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 --r and -R -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 ex_rep/base/rep_msg.c and supporting functions -in ex_rep/base/rep_net.c.

+ 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 DB_ENV + 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 + ex_rep/base/rep_net.c. Each member_t + contains the host and port identification, the environment ID, + and a file descriptor. +

+ 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 DB_EID_BROADCAST, 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 DB_ENV->rep_process_message() method. +

+ 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. +

+ This is implemented in the quote_send, quote_send_broadcast + and quote_send_one functions, which can be found in + ex_rep/base/rep_net.c. +

+ 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. +

+ The quote_send function is passed as the callback to + DB_ENV->rep_set_transport(); 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 DB_ENV->rep_process_message() on them as is convenient). In the sample + application, all messages transmitted are Berkeley DB messages + that get handled by DB_ENV->rep_process_message(), 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 DB_ENV->rep_process_message(). +

+ 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 + -l 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 -r and + -R 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 + ex_rep/base/rep_msg.c and supporting + functions in + ex_rep/base/rep_net.c. +

@@ -123,7 +146,8 @@ in ex_rep/base/rep_net.c.

Home - Ex_rep_base: putting it all together + Ex_rep_base: putting it all + together