Source: http://www.google.com/patents/US20070171919?ie=ISO-8859-1
Timestamp: 2015-08-04 13:26:15
Document Index: 589786748

Matched Legal Cases: ['Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60', 'Application No. 60']

Patent US20070171919 - Message batching with checkpoints systems and methods - Google PatentsSearch Images Maps Play YouTube News Gmail Drive More »Sign inAdvanced Patent SearchPatentsSystems and methods are provided for passing control of message dependencies and ordering to one or more network nodes participating in a transaction. Thus, messages can be sent to the participating nodes and the participating nodes can handle the messages according to their respective dependencies without...http://www.google.com/patents/US20070171919?utm_source=gb-gplus-sharePatent US20070171919 - Message batching with checkpoints systems and methodsAdvanced Patent SearchPublication numberUS20070171919 A1Publication typeApplicationApplication numberUS 11/262,314Publication dateJul 26, 2007Filing dateOct 28, 2005Priority dateOct 29, 2004Also published asUS8238350Publication number11262314, 262314, US 2007/0171919 A1, US 2007/171919 A1, US 20070171919 A1, US 20070171919A1, US 2007171919 A1, US 2007171919A1, US-A1-20070171919, US-A1-2007171919, US2007/0171919A1, US2007/171919A1, US20070171919 A1, US20070171919A1, US2007171919 A1, US2007171919A1InventorsPeter Godman, Skye Poier, Aaron Passey, Neal FachanOriginal AssigneeGodman Peter J, Poier Skye M, Passey Aaron J, Fachan Neal TExport CitationBiBTeX, EndNote, RefManReferenced by (8), Classifications (4), Legal Events (4) External Links: USPTO, USPTO Assignment, EspacenetMessage batching with checkpoints systems and methods
REFERENCE TO RELATED APPLICATIONS The present application claims priority benefit under 35 U.S.C. � 119(e) from U.S. Provisional Application No. 60/623,848, filed Oct. 29, 2004 entitled “Message Batching with Checkpoints Systems and Methods,” and U.S. Provisional Application No. 60/628,528, filed Nov. 15, 2004 entitled “Message Batching with Checkpoints Systems and Methods.” The present application also hereby incorporates by reference herein both of the foregoing applications in their entirety. The present application relates to U.S. application Ser. No. 11/______ [Attorney Docket ISIL.003A], titled “Non-Blocking Commit Protocol Systems and Methods,” filed on even date herewith, which claims priority to U.S. Provisional Application No. 60/623,843, filed Oct. 29, 2004 entitled “Non-Blocking Commit Protocol Systems and Method;” and U.S. application Ser. No. 11/______ [Attorney Docket ISIL.005A], titled “Distribution System with Asynchronous Execution Systems and Methods,” filed on even date herewith, which claims priority to U.S. Provisional Application No. 60/623,846, filed Oct. 29, 2004 entitled “Distribution System with Asynchronous Execution Systems and Methods,” and U.S. Provisional Application No. 60/628,527, filed Nov. 15, 2004 entitled “Distribution System with Asynchronous Execution Systems and Methods.” The present application hereby incorporates by reference herein all of the foregoing applications in their entirety.
DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS A program can be configured to batch multiple messages of a network operation. Batching is used to group multiple messages together into a collection that may be operated on as a whole. For example, an API may be configured to wait on all responses of a group of messages or to return a coalesced result code for a group of messages. Thus, responses from multiple asynchronous messages from one or more receiving nodes can be collected at the end of the batch and synchronized with the sending node. As used herein, an “initiator” is a node that starts, ends, sends messages and collects responses to the messages in the batch. A “participant” is a node that receives and executes messages in the batch. An artisan will recognize that an initiator can also be a participant. FIG. 1A illustrates a timing chart of a transaction 100 comprising batching of a plurality of messages sent between an initiator 102 (shown as “I”) and a participant 104 (shown as “P”). The initiator 102 begins the transaction 100 by sending a START message 106 to the participant 104. In this example, the START message 106 is a one-way message. Therefore, the initiator 102 does not expect a response and the participant 104 does not send a response. The initiator 102 may also send, for example, a synchronous message 108 (shown as “MSG_A”) to the participant 104. The participant 104 processes the synchronous message 108 for a period of time 110, after which it returns a response 112 (shown as “RSP_A”) corresponding to a result of processing the synchronous message 108. The initiator 102 may also send multiple asynchronous messages 114, 116, 118 (shown as “MSG_B,” “MSG_C” and “MSG_D,” respectively) to the participant 104. The participant 104 executes the asynchronous messages 114, 116, 118 in parallel during a time period 120. Then, the initiator 102 sends a COLLECT message 122 to the participant 104. In other embodiments, the initiator 102 expects the time period 120 to have ended after a certain time and then after such time, the initiator 102 sends a COLLECT message 122 to the participant 104. Upon receiving the COLLECT message 122, the participant returns a response 124 (shown as “RSP_BCD”) corresponding to results of processing the asynchronous messages 114, 116, 118. The initiator 102 then sends an END message 126 to the participant 104. While batching in the example shown in FIG. 1A allows responses to the asynchronous messages 114, 116, 118 to be grouped into the response 124, ordering and dependencies among the asynchronous messages 114, 116, 118 cannot be achieved without substantially increasing the amount of time required to complete the transaction 100. For example, suppose execution of the third asynchronous message 118 blocks continued execution of the transaction 100 unless the participant 104 successfully executes the first and second asynchronous messages 114, 116 sent by the initiator 102. To prevent such blocking, the first and second asynchronous messages 114, 116, could be changed to synchronous messages that would each return an individual response (not shown). The initiator could then send the third asynchronous message 118 after receiving each of the individual responses. However, this would add additional time to the transaction 100 since the synchronous messages 114, 116 would not run in parallel and would require extra time for the responses to be communicated from the participant 104 to the initiator 102. In another example shown in FIG. 1B, the initiator 102 can also avoid the blocking discussed above by sending the asynchronous messages 114, 116 to the participant 104 so they can be executed in parallel during a time period 128. The initiator 102 can then send a first COLLECT message 130 and receive a response 132 (shown as “RSP_BC”) corresponding the results of processing the asynchronous messages 114, 116. Following the response 132, the initiator 102 may send the asynchronous message 118 for the participant 104 to execute during a time period 135. Then, the initiator 102 can send a second COLLECT message 134 and receive a response 136 (shown as “RSP_D”) corresponding to the result of processing the asynchronous message 118. However, the added round trip of the additional COLLECT message 130 and the corresponding response 132 adds a substantial amount of time to the transaction 100. In one embodiment of the invention, a participant node passes control of message dependencies and ordering to one or more participant nodes in a transaction. In this way, messages can be sent in parallel to the participant nodes and the participant nodes can execute the messages according to their respective dependencies without first sending a response and waiting for the next message to arrive. In one embodiment, the participant nodes control message dependencies and ordering by receiving messages that are flagged with checkpoints in the batch to indicate that messages received before the checkpoint are to be executed before messages received after the checkpoint. In one embodiment, messages can also include error-handling information. For example, a message can be marked as “critical” such that if the message fails on a particular participating node, the initiator node does not send any more messages to that node until the critical error is cleared. Further, the participant node that had the critical failure discards any messages that have not yet been executed. When the initiator node wants to know the result of marked messages or wait until sent messages have been processed by the participant nodes, the initiator node can send a collect message to the participant nodes. Sending a collect message and receiving a response to the collect message guarantees all messages in the batch have been executed and responded to (if the message has a response), or discarded if a critical error was set. In one embodiment, collecting also clears the critical error condition. In the following description, reference is made to the accompanying drawings, which form a part hereof, and which show, by way of illustration, specific embodiments or processes in which the invention may be practiced. Where possible, the same reference numbers are used throughout the drawings to refer to the same or like components. In some instances, numerous specific details are set forth in order to provide a thorough understanding of the present invention. The present invention, however, may be practiced without the specific details or with certain alternative equivalent components and methods to those described herein. In other instances, well-known components and methods have not been described in detail so as not to unnecessarily obscure aspects of the present invention. I. System FIG. 2 is an exemplary block diagram of a network 200 according to one embodiment of the invention. The network 200 comprises a plurality of nodes 202, 204, 206 configured to communicate with each other through a communication medium 208. The communication medium 208 comprises, for example, the Internet or other global network, an intranet, a wide area network (WAN), a local area network (LAN), a high-speed network medium such as Infiniband, dedicated communication lines, telephone networks, wireless data transmission systems, two-way cable systems or customized computer interconnections including computers and network devices such as servers, routers, switches, memory storage units, or the like. The nodes 202, 204, 206 respectively comprise remote block manager modules 212, 214, 216. As used herein, the word module is a broad term that has its ordinary and customary meaning and also refers to logic embodied in hardware or firmware, or to a collection of software instructions, possibly having entry and exit points, written in a programming language, such as, for example, C or C++. A software module may be compiled and linked into an executable program, installed in a dynamic link library, or may be written in an interpreted programming language such as BASIC, Perl, or Python. It will be appreciated that software modules may be callable from other modules or from themselves, and/or may be invoked in response to detected events or interrupts. Software instructions may be embedded in firmware, such as an EPROM. It will be further appreciated that hardware modules may be comprised of connected logic units, such as gates and flip-flops, and/or may be comprised of programmable units, such as programmable gate arrays or processors. The modules described herein are preferably implemented as software modules, but may be represented in hardware or firmware. The remote block manager modules 212, 214, 216 are configured to control communication between the nodes 202, 204, 206 including, for example, transmitting messages, receiving messages, redistributing messages, executing received messages, providing responses to messages, combinations of the forgoing, or the like. In one embodiment, the remote block manager modules 212, 214, 216 are configured to communicate, RPC messages between nodes 202, 204, 206 over the communication medium 208 using TCP. An artisan will recognize from the disclosure herein, however, that other message or transmission protocols can be used. In one embodiment, at least one of the nodes 202, 204, 206 comprises a storage unit in a distributed file system as described in U.S. patent application Ser. No. 10/007,003, filed Nov. 9, 2001, which is herein incorporated by reference. In addition, or in other embodiments, at least one of the nodes 202, 204, 206 may comprise a conventional computer or any device capable of communicating with the network 200 including, for example, a computer workstation, a LAN, a kiosk, a point-of-sale device, a personal digital assistant, an interactive wireless communication device, an interactive television, a transponder, or the like. In a transaction among the nodes 202, 204, 206, one of the nodes 202, 204, 206 is configured to act as an initiator and one or more of the nodes 202, 204, 206 are configured to act as participants. In some embodiments, any of the nodes 202, 204, 206 may be selected to act as the initiator. In other embodiments, the initiator may be selected based at least in part on a service provided by at least one participant node requested by the initiator in the transaction. In some embodiments, an initiator may also be a participant in a particular transaction. An artisan will recognize from the disclosure herein that the network 200 is not limited to the three nodes 202, 204, 206 shown in FIG. 2 and may comprise any number of nodes including, for example, one node, two nodes, or greater than three nodes. Further, any number of nodes may be configured as participants in a particular transaction including, for example, only one participant. In the exemplary embodiment shown in FIG. 2, the node 202 is configured as an initiator (hereinafter, the “initiator node 202”) and the nodes 204, 206 are configured as participants (hereinafter, the “participant nodes 204, 206”). A. Remote Block Manager in Initiator Mode The remote block manager module 212 of the initiator node 202 is configured to group messages together into a batch that may be operated on as a whole. As discussed in more detail below, the remote block manager module 212 of the initiator node 202 is configured to start a batch, end the batch, send messages in the batch, and collect any responses to the messages. 1. Checkpoints The remote block manager module 212 is also configured to set one or more checkpoints in the batch in order to pass control of message dependencies and ordering to the participant nodes 204, 206. For example, the initiator node 202 can set a checkpoint between asynchronous messages sent in parallel to the participant nodes 204, 206 to signal that messages sent before the checkpoint are to be executed before messages sent after the checkpoint. Thus, delay in the overall transaction can be reduced because the initiator node 202 does not have to collect responses before sending messages that depend on the execution of prior messages. In one example, a required input of message X in a batch could be an output of a previous message; such that message X depends upon the previous message. Separate checkpoint messages can be sent to the participant nodes 204, 206. In a preferred embodiment, however, the initiator node 202 does not send separate checkpoint messages. Rather, the remote block manager module 212 is configured to flag the next message in the batch to be sent to the participant nodes 204, 206 to indicate that a checkpoint precedes its handling. Thus, avoiding the time required to transmit a separate checkpoint message across the communication medium 208 reduces the delay in the overall transaction. Further, multiple checkpoints set by the remote block manager module 212 without an intervening message can be treated as a single checkpoint without a performance penalty that may be caused by a separate checkpoint message being sent across the network 200 to the participant nodes 204, 206. In some embodiments, a checkpoint can be set on messages sent to a portion of the participant nodes 204, 206. For example, the remote block manager module 212 may be configured to set a particular checkpoint on a message sent to the participant node 204 without setting the checkpoint on the message sent to the participant node 206. 2. Marking Messages In one embodiment, the remote block manager module 212 of the initiator node 202 is also configured to handle message failures by marking one or more messages in the batch as “critical.” If a critical message fails on one or more of the participant nodes 204 (for example, the remote block manager module 212 receives a “failure message” from one or more of the participant nodes), 206, the remote block manager module 212 is configured to stop sending messages to the node that had the failure. In some embodiments, the remote block manager module 212 may continue to send non-critical messages to the node that had the failure while not sending critical messages. The remote block manager 212 may also be configured to mark certain messages to ignore a critical failure. For example, a message may be flagged to be sent to the participant node 204 even if a critical failure has already been reported on that node 204. As another example, a message may be flagged to be run on the participant node 204 even after a critical failure has occurred. In one embodiment, the remote block manager 212 may mark messages by sending a particular code in the message, though other marking techniques may be used. 3. Collecting Responses The remote block manager module 212 of the initiator node 202 is also configured to synchronize with the participant nodes 204, 206 by collecting any responses to messages previously sent in the batch. Thus, the batch can be collected to verify the result of critical messages in the batch or wait until all messages have been processed by the participant nodes. In one embodiment, the remote block manager module 212 is configured to collect the batch by sending collect messages to the participant nodes 204, 206. In addition, or in other embodiments, collecting the batch clears any critical error condition that may exist on the initiator node so the batch can be used for any failure cleanup functions or cancellation messages. B. Remote Block Manager in Participant Mode The remote block manager modules 214, 216 of the respective participant nodes 204, 206 are configured to receive and execute messages in the batch and to send responses to the initiator node 202. The remote block manager modules 214, 216 are configured to execute one or more received messages in parallel and to start executing the messages in the order the messages were sent from the initiator node 202. However, if a message is flagged with a checkpoint, the remote block manager modules 214, 216 will not execute the message or any subsequent messages until the messages sent up to the checkpoint have been executed to completion. Thus, the remote block manager modules 214, 216 in the participant nodes 204, 206 can handle message dependencies without sending responses to the initiator node 202 and then waiting for the dependent message to be received. As discussed above, the remote block manager modules 214, 216 of the respective participant nodes 204, 206 may receive one or more messages marked as critical. If a critical message fails during execution, messages that have not yet been processed will be discarded on the node that had the failure. In one embodiment, messages already being processed when the critical failure occurs will continue to run to completion. However, new messages or messages received but not yet executed will be discarded by the node that had the critical failure. As also discussed above, the remote block manager modules 214, 216 may be configured to execute certain flagged messages even after a critical failure has occurred. In some embodiments, after a critical failure has occurred, the remote block manager module 212 may send a “failure message” to the initiator node 202. Furthermore, in some embodiments, the remote block manager module 212 sends a status message for each message marked critical. Upon receiving a collect message from the initiator node 202, each of the remote block manager modules 214, 216 of the respective participant nodes 204, 206 are configured to return a response comprising the results of one or more messages received since a previous collect message, if any, was received. The results may include, for example, indication that a critical failure has occurred during the execution of a message. If a critical failure has occurred on a node, the respective remote block manager module 214, 216 will not return a response to the collect message until queued messages on or in-transit to the node are discarded and currently executing messages have run to completion. For a node that did not have a critical failure, the respective remote block manager module 214, 216 will not return a response to the collect message until queued messages on, in-transit to, or already running have been executed to completion. In addition, or in other embodiments, the remote block manager modules 214, 216 are configured to clear any critical error condition that may exist on its respective participant node 204, 206. II. Exemplary Timing Diagram FIG. 3 illustrates an exemplary timing diagram of a transaction 300 comprising batching of a plurality of messages sent between an initiator 302 (shown as “I”), a first participant 304 (shown as “P1”) and a second participant 305 (shown as “P2”) according to an embodiment of the invention. An artisan will recognize from the disclosure herein that two participants 304, 305 are shown for illustrative purposes and that any number of participants could be involved in the transaction 300. The initiator 302 begins the transaction 300 by sending START messages 306 to the participants 304, 305. The exemplary START messages 306 are one way messages and do not have responses. The initiator 302 also sends a synchronous message 308 (shown as “MSG_A”) to the participants 304, 305. In this example, the batch includes a first checkpoint 307 between the sending of the START message 306 and the synchronous message 308. Thus, the synchronous message 308 includes a flag to indicate the occurrence of the first checkpoint 307 in the batch. Therefore, the participants 304, 305 do not execute the synchronous message 308 until the START message 306 executes to completion. The participants 304, 305 process the synchronous messages 308 for respective periods of time 310, 310′, after which they return responses 312 (shown as “RSP_A”) corresponding to respective results of processing the synchronous message 308. After receiving the responses 312, the initiator 302 sends first asynchronous messages 314 (shown as “MSG_B”), second asynchronous messages 316 (shown as “MSG_C”) and third asynchronous messages 318 (shown as “MSG_D”) to the participants 304, 305. An artisan will recognize that the periods of time 310, 310′ or other time periods depicted in transaction 300 can be of arbitrary length and may be of differing lengths, possibly resulting in responses 312 or other responses being returned in an arbitrary order. In this example, the batch includes a second checkpoint 317 between the second asynchronous messages 316 and the third asynchronous messages 318. Thus, the third asynchronous messages 318 include a flag to indicate the occurrence of the second checkpoint 317 in the batch. Therefore, the participants 304, 305 each execute the first asynchronous messages 314 and the second asynchronous messages 316 in parallel during respective time periods 320, 320′. After the first asynchronous messages 314 and the second asynchronous messages 316 execute to completion, the participants 304, 305 each execute the third asynchronous message 318 during respective time periods 321, 321′. The initiator 302 then sends COLLECT messages 322 to the participants 304, 304. In some embodiments, the initiator 302 waits an expected elapsed time corresponding, for example, to the time periods 320, 320′, 321, 321′ before sending the COLLECT messages 322 to the participants 304, 305. Upon receiving the COLLECT messages 322, the participants 304, 305 return respective responses 324 (shown as “RESP_BCD”) corresponding to results of processing the asynchronous messages 314, 316, 318. The initiator 302 then sends END messages 326 to the participants 302, 304. The exemplary END messages 326 are one way messages and do not have responses. As the above example illustrates, the initiator 302 can push control of message dependencies onto the participants 304, 305 by including checkpoints 307, 317 in the batch. The initiator 302 is guaranteed that the START message 306 will execute to completion before the synchronous message 308 executes even though the initiator 302 does not receive a response to the START message 306. Similarly, the initiator 302 can send the three asynchronous messages 314, 316, 318 without waiting for responses and still be guaranteed that the first asynchronous message 314 and the second asynchronous message 316 will execute to completion before the third asynchronous message 318 is executed. Thus, the transaction 300 can include message dependencies without substantially increasing the overall time of the transaction 300. III. Distributed File System Example In one embodiment, the message batching system may be used in a distributed file system, such as the systems described in U.S. patent application Ser. No. 10/007,003, filed Nov. 9, 2001 which claims priority to Application No. 60/309,803 filed Aug. 3, 2001, and U.S. patent application Ser. No. 10/714,326, filed Nov. 14, 2003, which claims priority to Application No. 60/426,464, filed Nov. 14, 2002, all of which are hereby incorporated herein by reference in their entirety. For example, the message batching system may be used to determine if write commands to the distributed nodes have executed without any failures before the original copies of the write data are deleted from the system. As another example, the message batching system may be used to ensure that the location of error correction data related to the write data has been stored before allowing reads to that data. FIGS. 4A-4C (collectively, “FIG. 4”) and FIG. 5 illustrate exemplary processes according to one embodiment of the invention for sending messages among nodes in a distributed file system, such as the distributed file system described in U.S. patent application Ser. No. 10/007,003, filed Nov. 9, 2001. For illustrative purposes, FIGS. 4 and 5 are discussed below in relation to exemplary pseudocode. Further, corresponding pseudocode examples can be found in the attached Appendix which forms a part of the patent application. It should be recognized, however, that the exemplary pseudocode is not meant to limit the scope of the invention, but only to provide details for a specific embodiment. The nodes in the distributed file system comprise smart storage units that each comprise a remote block manager (RBM) configured to send RPC messages over a network using a reliable protocol such as TCP. As used herein, an “update-RPC” message is sent one-way with no response and an “RPC” message is an asynchronous or synchronous message that expects a response. For a particular transaction, one node acts as an initiator to start, end and collect a message batch. There are also one or more participant nodes that receive and execute the messages in the batch using “dev_local” message handlers. The one or more participant nodes may also send responses back to the initiator. The initiator may also be a participant in the transaction. A. Initiator Process FIG. 4 illustrates a process 400 usable by an initiator to manage a transaction between nodes. In a block 402, the initiator starts a batch. The initiator creates an empty batch with the following function:
wherein bid is the returned identifier from the rbm_batch_start function. In this example, setting a checkpoint flag in the message in a block 414 sets the checkpoint. In a block 416, the initiator queries whether there are additional message modifiers (i.e., other than the checkpoint flag). As discussed above, the additional message modifiers may include, for example, flags to mark the message as critical, as a message that should always be run, as a message that should always be sent, or the like. In one embodiment, all messages are marked as critical by default. In a block 418, the initiator sets the modifier flags. The initiator may also check to see if any prior critical errors have cleared before sending messages. This check may be performed in the process 400, for example, anytime before the send message block 420. If prior critical errors have cleared, the initiator may proceed to block 420 and send the message. If not, then the initiator may wait until the critical error has cleared before sending any more messages. In other embodiments, the initiator may continue to send non-critical messages, but wait until the critical error is cleared before sending any critical messages. In a block 420, the initiator sends the message by calling the following: struct rbm_batch_slot_id_t { efs_devid_t devid; efs_seqno_t seqno; }; int rbm_batch_FOO(rbm_batch_id_t bid, efs_devid_t devid, struct rbm_batch_slot_id_t *slot_id, u_int opts, in_args..); wherein the bid is the returned identifier from the rbm_batch_start function, devid is a device identifier of the destination (i.e., participant node) where the message is to be sent, and in_args define the arguments for the FOO message being sent. As discussed below, the slot_id parameter points to a preallocated memory area where a unique identifier is stored that is later used to lookup data returned by the message. Since update-RPC messages do not return data that needs to be fetched later, they do not have slot_id parameters. The opts parameter is used to set the additional message modifier flags discussed above and may be any combination of the following: /* Turn off marking the message “critical” (default: on) */ #define RBMB_NONCRITICAL 0x0001 #define RBMB_ALWAYS_RUN 0x0002 #define RBMB_ALWAYS_SEND 0x0004. Since update_RPC messages do not have responses to communicate a success or failure back to the initiator, they cannot be marked as critical and the opts parameter is omitted. However, in one embodiment, an update_RPC message can be made critical by changing it to an RPC message and discarding the response portion of the RPC message on the participant. This saves a round trip for messages where the normal response is not needed to proceed but an indication of success or failure is desired. In the block 430, the initiator may select the option of looking up responses to message in the batch by calling the function: int rbm_batch_lookup_FOO(rbm_batch_id_t bid, struct rbm_batch_slot_id_t *slot_id, int *response_code, out_args..); wherein this lookup function fills out_args with the message response slot identified by the <bid, slot_id> token and frees the batch's internal storage associated with the slot_id. Until the lookup function is called, the response messages are held in the batch as a chain of mbufs in the order they arrived over the network. If the message response has not yet arrived when the lookup function is called, the RBM will stay in a block 432 until the response is received in a block 436, the initiator receives notification that the message was discarded (for example, due to a critical error) in a block 438 or the participant disconnects from the network in a block 440. In a block 442, the lookup function fetches the message response and in a block 444 queries whether the response indicates that a critical error has occurred. If a critical error has occurred, the RBM sets a critical error condition in the initiator and new calls to rbm_batch_FOO will fail immediately. As discussed above, in some embodiments, if a critical error has occurred, the initiator may continue to send non-critical messages, but wait for the critical error to clear before sending critical messages. In the block 450, the initiator may select the option of collecting the batch, wherein the process 400 proceeds to a block 452. In the block 452, the initiator sends a collect message to the participants by calling the following function:
wherein the bid parameter is the returned identifier from the rbm_batch_start function. In one embodiment, this function will not execute until all messages on all participants are complete. The function then removes the associated data structures on all nodes so that the batch can no longer be operated on and invalidates the bid parameter. B. Participant Process FIG. 5 illustrates a process 500 usable by a participant in a transaction between nodes. In a block 502, the participant receives a start message from the initiator. The start message includes the bid parameter discussed above to uniquely identify the batch. Once the batch has been opened, the participant determines whether a current message has been received in a block 504, whether a collect message has been received in a block 506, or whether an end message has been received in a block 508. If a current message has been received in the block 504, the process 500 queries in a block 510 whether current message includes a checkpoint flag. If yes, the process proceeds to a block 512 wherein it waits until the previously received messages, if any, have been processed. If the checkpoint flag was not set in the current message or the previous messages have been processed, the process proceeds to a block wherein it queries whether a critical error condition has been set in the participant. If yes, the process 500 discards unprocessed messages, if any, in a block 516. If a critical error condition is not set in the participant, the participant processes the current message in a block 518. In a block 520, the participant queries whether the current message failed. If yes, in a block 522, the participant queries whether a critical error flag is set in the current message. If the critical error flag is set, process 500 sets the critical error condition in the participant. If the collect message has been received in the block 506, the process 500 queries in a block 526 whether the critical error condition is set in the participant. If the critical error condition is set in the participant, the process 500 waits in a block 528 until queued messages, if any, on or in-transit to the participant have been discarded. In some embodiments, if the critical error condition is set in the participant, the process 500 allows non-critical messages to remain active (for example, to remain in the queue) and only discards critical messages. In a block 530, the process queries whether all remaining messages on the participant are complete. If yes, the process 500 sends all outstanding message responses to the initiator in a block 532 and clears the critical error condition, if one exists, in the block 534. If an end message has been received in the block 508, the process proceeds to a block 536 wherein the participant removes data structures corresponding to the batch and invalidates the bid parameter. While certain embodiments of the inventions have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the inventions. Indeed, the novel methods and systems described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions and changes in the form of the methods and systems described herein may be made without departing from the spirit of the inventions. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope and spirit of the inventions. APPENDIX This Appendix forms a part of the patent application entitled “MESSAGE BATCHING WITH CHECKPOINTS SYSTEMS AND METHODS,” attorney docket number ISIL.004A. This Appendix includes exemplary pseudocode for a remote block manager module (rbm) configured to send messages over a network between an initiator node and one or more participant nodes. It should be recognized, however, that the exemplary pseudocode is not meant to limit the scope of the invention, but only to provide details for a specific embodiment. This Appendix includes the Appendices incorporated by reference above from U.S. Provisional Application No. 60/623,848, filed Oct. 29, 2004 entitled “Message Batching with Checkpoints Systems and Methods,” and U.S. Provisional Application No. 60/628,528, filed Nov. 15, 2004 entitled “Message Batching with Checkpoints Systems and Methods,” which are hereby incorporated by reference herein in their entirety. ------------------------------------------------------------------------- Generic (initiator and participant) pseudo-code: efsidp_dispatch if msg.hdr.batch_id != 0 if msg is response /* initiator side */ rbm_lbatch_addresp(dev, mbuf) else /* participant side */ efsidp_dispatch_rbatch_msg(dev, mbuf) return else [existing dispatch code path] disconnect_cb(ctx, dev) /* Take care of initiator side - batches to dev */ foreach batch in g_lbatch if not (batch.devs contains dev) continue foreach batch_msg_ctx in batch.dev.msg_ht if not ctx.mbuf ctx.discarded = 1 wakeup ctx batch.dev.need_collect = 0 batch.dev.wait_count = 0 wakeup(batch.dev.wait_count); /* Take care of participant side - batches from dev */ foreach batch in g_rbatch if dev is not initiator continue rbm_rbatch_end(dev, bid) ------------------------------------------------------------------------- initiator (aka “local”) pseudo-code: rbm_batch_start(bidp) batch = alloc new lbatch batch.id = get next g_lbatch id (never zero) add_to_hash(g_lbatch.batch_ht, batch.id, batch) rbm_batch_FOO(bid, devid, slot_id, opts, in_args..) batch_ctx.flags = 0 batch_ctx.bid = bid rbmd_usable(devid) if error return seqno = rbmd_next_seq(devid) /* CRITICAL is on by default */ if (!(opts & RBMB_NONCRITICAL)) batch_ctx.flags |= IDP_BATCH_CRITICAL /* slot_id NULL if this is an “update-rpc” message */ rbm_lbatch_addmsg(bid, dev, slot_id, seqno, type, &batch_ctx.flags) if error return efsidp_foo(devid, seqno, batch_ctx, in_args..) if error rbm_lbatch_cancelmsg(bid, dev, slot_id, seqno) rbm_lbatch_addmsg(bid, dev, slot_id, seqno, type, flags) batch = rbm_lbatch_lookup(bid) if dev not in batch alloc and add batch_dev to batch flags |= batch.dev.next_msg_flags batch.dev.next_msg_flags = 0 if batch.critical_error && !(flags & CLEAR_ERROR) return ECANCELED if (slot_id) /* getting a response */ zero slot_id /* Add msg to batch's msg_ht */ batch_msg_ctx = alloc; add_to_hash(batch.dev.msg_ht, seqno, batch_msg_ctx) slot_id.dev = dev slot_id.seqno = seqno /* having a slot implies SEND_RESPONSE */ flags |= IDP_BATCH_SEND_RESPONSE /* inc count of responses to wait for in collect */ batch.dev.wait_count++ else /* we must send a collect message */ batch.dev.need_collect = 1 rbm_lbatch_cancelmsg(bid, dev, slot_id, seqno) batch = rbm_lbatch_lookup(bid) if (slot_id) batch_msg_ctx = del_from_hash(batch.dev.msg_ht, seqno) free batch_msg_ctx rbm_lbatch_dec_wait_count(batch, dev) zero slot_id rbm_lbatch_addresp(dev, mbuf) seqno = hdr.seqno bid = hdr.batch_id flags = hdr.batch_flags batch = rbm_lbatch_lookup(bid) batch_msg_ctx = find_in_hash(batch, seqno) if error free mbuf return error if flags & CRITCAL_ERROR batch.critical_error = 1 /* TODO flags & CANCEL? how to handle new any-msg-resp? */ batch_msg_ctx.mbuf = mbuf /* unblock any lookup_FOO for this message */ wakeup(batch_msg_ctx) rbm_lbatch_dec_wait_count(batch, dev) rbm_lbatch_dec_wait_count(batch, batch_dev) batch_dev.wait_count−− if 0 eq batch_wait_count /* unblock any collects */ wakeup batch_dev.wait_count rbm_batch_checkpoint(bid) batch = rbm_lbatch_lookup(bid) foreach dev in batch batch.dev.next_msg_flags |= CHECKPOINT /* Only generated for “rpc” messages */ rbm_batch_lookup_FOO(bid, slot_id, response_code, out_args..) response_code = 0 /* may block */ rbm_lbatch_lookup_resp(bid, slot_id, &mbuf) if error return error mbuf_istream_init(mis, mbuf, hdr.size) rbm_response_code = FOO_resp_unmarshal(mis, &response_code, ..) mbuf_istream_clean(mis) rbm_lbatch_lookup_resp(bid, slot_id, mp) *mp = 0 dev = slot_id.dev if dev == 0 return EINVAL batch = rbm_lbatch_lookup(bid) batch_msg_ctx = get_from_hash(batch.dev.msg_ht, slot_id.seqno) if error error = ENOENT goto out_unlock while !batch_msg_ctx.mbuf && !batch_msg_ctx.discarded sleep(batch_msg_ctx, batch->lock) del_from_hash(batch.dev.msg_ht, slot_id.seqno) if batch_msg_ctx.discarded error = ECANCELED goto out_unlock /* pass raw response data back to caller */ mp = &batch_msg_ctx.mbuf out_unlock: free batch_msg_ctx rbm_batch_collect(bid) rbm_batch_collect_flags(bid, 0) rbm_batch_collect_flags(bid, flags) batch = rbm_lbatch_lookup(bid) /* send collect messages or wait for msg responses */ /* will be no bigger than this */ slots = alloc slots * (n devs in batch) n_coll = 0; foreach dev in batch /* always clear error on collect */ batch.dev.next_msg_flags |= CLEAR_ERROR /* * CLEAR_ERROR implies checkpoint - we want to be * sure everything before the next msg has completed. */ batch.dev.next_msg_flags |= CHECKPOINT if batch.dev.need_collect rbm_batch_batch_collect(bid, dev, &slots[n_coll], 0); n_coll++ else if batch.dev.wait_count /* all msgs have responses, wait for them */ while batch.dev.wait_count sleep(batch.dev.wait_count, batch.lock) /* wait for any collect message responses */ i = 0 foreach dev in batch if batch.dev.need_collect ASSERT(i < n_coll) error = lookup_batch_collect(bid, &slots[i], &code) if (error || code == ECRITFAIL) batch.critical_error = 1 batch.dev.need_collect = 0 i++ if batch.critical_error error = ECRITFAIL batch.critical_error = 0 return error rbm_batch_end(bid) batch = rbm_lbatch_lookup(bid) /* force sending a collect message */ foreach dev in batch batch.dev.need_collect = 1 rbm_batch_collect_flags(bid, FINAL) /* continue even if rbm_batch_collect fails */ remove from g_lbatch free batch ------------------------------------------------------------------------- Participant (aka “remote”) pseudo-code: efsidp_dispatch_rbatch_msg(dev, mbuf) seqno = hdr.seqno bid = hdr.batch_id flags = hdr.batch_flags if not batch = rbm_rbatch_lookup(dev, bid) batch = rbm_rbatch_start(dev, bid) if flags & CHECKPOINT rbm_rbatch_inc_cp(batch) /* clear flag - don't do it again if !canrun */ hdr.batch_flags &= {circumflex over ( )}CHECKPOINT batch.cp_last.msg_cnt++ if rbm_rbatch_canrun(batch, batch.cp_last) if flags & CLEAR_ERROR batch.critical_error = 0 if batch.critical_error if flags & SEND_RESPONSE TODO new any-resp fail msg m_freem(mbuf) rbm_rbatch_msg_done(dev, bid) return /* construct batch_ctx for response */ batch_ctx.batch_id = bid batch_ctx.flags = flags; if g_msg_info[hdr->type].own_thread efsidp_dispatch_thread(dev, mbuf, batch_ctx) else result = handle_FOO(dev, mbuf, batch_ctx) else append mbuf to batch.cp_last.pending rbm_rbatch_start(dev, bid) batch = alloc new rbatch(M_ZERO) batch.id = bid batch.dev = dev batch_uid = pack(dev, bid) add_to_hash(g_rbatch.batch_ht, batch_uid, batch) /* alloc cp 0 */ rbm_rbatch_inc_cp(batch) rbm_rbatch_lookup(dev, bid) batch_uid = pack(dev, bid) get_from_hash(g_rbatch.batch_ht, batch_uid) rbm_rbatch_inc_cp(batch) alloc new cp cp.id = batch.next_cp_id batch.next_cp_id++ add_to_hash(batch.cp_ht, cp) batch.cp_last = cp rbm_rbatch_advance_cp(batch) rbm_rbatch_advance_cp(batch) while (batch.cp_active.msg_cnt == 0) and (batch.cp_active != batch.cp_last) wakeup batch.cp_active batch.cp_active = get_from_hash(batch.cp_ht, batch.cp_active.id + 1) ASSERT(batch.cp_active) rbm_rbatch_canrun(batch, cp) if batch.cp_active.id eq cp.id return true /* implies batch.cp_active.id < cp.id */ return false rbm_rbatch_msg_done(dev, batch_ctx, result) batch = rbm_rbatch_lookup(dev, ctx.bid) if result and batch_ctx.flags & CRITICAL batch.critical_error = 1 rbm_rbatch_dec_cp_msg(dev, batch) if ctx.flags & FINAL rbm_rbatch_end(dev, bid) rbm_rbatch_dec_cp_msg(batch) ASSERT(batch.cp_active.msg_cnt) batch.cp_active.msg_cnt−− old_cp = batch.cp_active rbm_rbatch_advance_cp(batch) /* if we advanced the cp, kick off processing */ if old_cp != batch.cp_active work.action = DWT_BATCH work.data.bid = batch.id dwt_dispatch(work) rbm_rbatch_end(dev, bid) batch = rbm_rbatch_lookup(bid) while batch.cp_last.msg_cnt msleep(batch.cp_last, batch.lock) remove_from_hash(g_rbatch.dev, batch.id) free batch dev_local_batch_collect(dev, seq_no, batch_ctx, bid) if not batch = rbm_rbatch_lookup(dev, bid) send ENOENT /* * if we're running, then our collect cp must have been * reached, so all we have to do is return the status. * the initiator guarantees no more messages have been * added to this checkpoint until it receives this collect * response. */ if batch.critical_error response = ECRITFAIL /* discard batch_ctx to undo munging in efsidp_dispatch */ efsidp_batch_collect_resp(dev, seq_no, NULL, response); efsidp_FOO_resp(dev, seqno, batch_ctx, args...) ... batch_id = 0 batch_flags = 0 if batch_ctx batch_id = batch_ctx.batch_id if response_code and batch_ctx.flags & CRITICAL batch_flags |= CRITICAL_ERROR if not batch_ctx or batch_ctx.flags & SEND_RESPONSE efsid_send(id, type, mos, gi, seqno, batch_ctx) if batch_ctx rbm_rbatch_msg_done(ctx.dev, ctx.batch_ctx, result) ... dwt_main ... for (;;) { ... case DWT_BATCH: rbm_batch_dwt_dispatch(dev, work.bid) ... rbm_batch_dwt_dispatch(dev, bid) batch = rbm_rbatch_lookup(dev, bid) mbuf = pop(batch.cp_active.mbuf) /* One at a time, please */ efsidp_dispatch_rbatch_msg(dev, mbuf) /* More to do? Interleave with other dwt work */ if batch.cp_active.mbuf work.action = DWT_BATCH work.data.bid = batch.id dwt_dispatch(work) ------------------------------------------------------------------------- The following is in the IDP (Isilon Device Protocol) header packet: struct efsid_header { ... rbm_batch_id_t batch_id; u_int8_t batch_flags; }; Where batch_flags may be: #define IDP_BATCH_CRITICAL 0x01 #define IDP_BATCH_CRITICAL_ERROR 0x02 #define IDP_BATCH_CHECKPOINT 0x04 #define IDP_BATCH_CLEAR_ERROR 0x08 #define IDP_BATCH_SEND_RESPONSE 0x10 #define IDP_BATCH_FINAL 0x20 The following is a pointer parameter to all efsidp_FOO, efsidp_FOO_resp and dev_local_FOO functions: struct efsidp_batch_ctx { rbm_batch_id_t batch_id; u_int8_t batch_flags; }; New RBM message for batch collection. Batch ID etc transmitted via efsid_header. Note this is *not* a batchable message, but can be treated like one when processed by the participant. rpc batch_collect { callers: async; handler: async; group-info: none; options: thread, response-refcount, proto-open; args { rbm_batch_id_t batch_id; } response { int response_code; response-code: response_code; } } Generic resp (new type)—
New RBM message sent in the following cases: when a CRITICAL message with no SEND_RESPONSE fails when any type of incoming message with SEND_RESPONSE is discarded on the remote side due to an error occurring on a previous CRITICAL message This message will take the following format: update-rpc rpc_cancel { group-info: none; args { efs_seqno_t rpc_seqno; # must be set rbm_batch_id_t batch_id; # zero to ignore int response_code; } } Referenced byCiting PatentFiling datePublication dateApplicantTitleUS7346720Oct 21, 2005Mar 18, 2008Isilon Systems, Inc.Systems and methods for managing concurrent access requests to a shared resourceUS7386675Oct 21, 2005Jun 10, 2008Isilon Systems, Inc.Systems and methods for using excitement values to predict future access to resourcesUS7890955 *Apr 3, 2006Feb 15, 2011Microsoft CorporationPolicy based message aggregation frameworkUS8335171 *Oct 27, 2009Dec 18, 2012Juniper Networks, Inc.NETCONF-enabled provisioning in rollback agnostic environmentUS8345553 *Mar 3, 2008Jan 1, 2013Broadcom CorporationApparatus and methods for reduction of transmission delay in a communication networkUS8724485Jan 30, 2008May 13, 2014Broadcom CorporationHome network system and methodUS8953494Dec 17, 2012Feb 10, 2015Juniper Networks, Inc.NETCONF-enabled provisioning in rollback agnostic environmentUS9094226Sep 4, 2002Jul 28, 2015Broadcom CorporationHome network system and method* Cited by examinerClassifications U.S. Classification370/396International ClassificationH04L12/56Cooperative ClassificationH04L67/40European ClassificationH04L29/06LLegal EventsDateCodeEventDescriptionJul 24, 2006ASAssignmentOwner name: ISILON SYSTEMS, INC., WASHINGTONFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:GODMAN, PETER J.;PASSEY, AARON J.;FACHAN, NEAL T.;REEL/FRAME:018114/0765Effective date: 20060103Mar 31, 2011ASAssignmentOwner name: ISILON SYSTEMS LLC, WASHINGTONFree format text: MERGER;ASSIGNOR:ISILON SYSTEMS, INC.;REEL/FRAME:026066/0785Effective date: 20101229Apr 4, 2011ASAssignmentEffective date: 20101229Owner name: IVY HOLDING, INC., MASSACHUSETTSFree format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:ISILON SYSTEMS LLC;REEL/FRAME:026069/0925Apr 6, 2011ASAssignmentEffective date: 20101231Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:IVY HOLDING, INC.;REEL/FRAME:026083/0036Owner name: EMC CORPORATION, MASSACHUSETTSRotateOriginal ImageGoogle Home - Sitemap - USPTO Bulk Downloads - Privacy Policy - Terms of Service - About Google Patents - Send FeedbackData provided by IFI CLAIMS Patent Services