#include <rock.h>

Public Member Functions | |
| rock_datagram_reply (rock_datagram_message *msg) | |
| Create a reply object. | |
| virtual void | run ()=0 |
| handle the reply. | |
Protected Attributes | |
| rock_datagram_message * | msg |
| the message that was sent | |
| rock_datagram_message * | ack_msg |
| The ACK message that was received. | |
Friends | |
| class | rock |
It has a pure virtual, the run() method, which you must implement.
| karoo::rock_datagram_reply::rock_datagram_reply | ( | rock_datagram_message * | msg | ) |
Create a reply object.
This object will be associated with a rock_datagram_message that is to be sent. Then when the ACK is received, this reply object will be run in the general_pool.
| msg | the message that this reply is associated with. |
| virtual void karoo::rock_datagram_reply::run | ( | ) | [pure virtual] |
handle the reply.
Typically what you'd have in here is a parser that reads the type of the ack_msg, and its reply data (if any) and then runs some operation... or, you may create a new class for each section of the code. This run() in effect carries on where the "caller" (which sent the datagram) left off. In this sense it will be like a "return" from a function, the "function call" being the sending of the datagram, and the execution of the "function" happening remotely.
rock_datagram_message* karoo::rock_datagram_reply::ack_msg [protected] |
The ACK message that was received.
If this is NULL, then it means that the ACK was not received, and in fact, the run() method is called in this case for a NACK.
1.5.8