4. Temporary Device Type Message Event

The default message event for a temporary device type is implemented by the Tempnodetype class in the Khala framework. Login, Devtpye, and islogin three message events are now implemented by default, and these message events do not require a device to log on, and any connection can obtain a message response of that type. Where login involves login lifecycle management, it is not possible to override the event to preserve it. Other message events can be overridden by the user according to the actual business requirements, or a new temporary device type message event is added.

1. Overriding temporary device type messages

We can meet the actual requirements by overriding the temporary device type messages that are implemented by the Khala default, as described in overriding Devtpye as an example:

The Devtype message event refers to the type of device that gets the current connection, or Temp_type if the device is not logged on, or login_type if the device is logged on, and the more specific device type can be extended on the logged-on device basis. In the client test, the response to the Devtpye, IsLogin request event is also obtained when the connection is not logged in.

We first create a new class called Mytempnodetype, which inherits from the Tempnodetype class and overrides the Ondevtypemsg method in the class. In the new method, we use the phrase "This is my Devtype" to differentiate the implementation of the original Devtype while the send connects to the specific device type.

classMytempnodetype: PublicKhala::tempnodetype { Public: Mytempnodetype (); Virtual~Mytempnodetype (); //overriding Devtype response events for the Tempnodetype class    Virtual BOOLOndevtypemsg (khala::infonodeptr& infonodeptr, json::value&msg, Khala::timestamp time) {std::stringDevtype = infonodeptr->Getnodetype (); Infonodeptr->send ("This is my devtype:"+devtype); return true; }};

Also in the main function, we register our newly created Mytempnodetype class with Nodeserver.settempnodetypeinstance (&mytempnodetype) to the system.

int Main () {    inetaddress listenaddr (user_port);    Nodeserver Nodeserver (LISTENADDR);     // Create a Mytempnodetype object     mytempnodetype mytempnodetype;     // register the object as a new Tempnodetype    Nodeserver.settempnodetypeinstance (&mytempnodetype);    Nodeserver.start (user_server_thread_num);     return 0 ;}

　　

With the two simple steps above, it is convenient to rewrite the Devtpye transient device type message response event. At this point we can run the new server-side program and start the client for testing:

2. Create a new temporary device type message

Obviously the default of two temporary device type messages is not sufficient for our service-side system requirements, and the Khala framework also provides a way to create new non-logon message response events. This is done by creating a temporary device type message that gets the current system time.

You must first set a message type for this event, and you can add Time_type to the./include/khala/parsekey.h. The newly added message type must be a string that is uniquely set.

// This is the default msg type #define Login_type "Login"#define logout_type "LOGOUT"#define dev_type "DEV"#define Is_login_type "IsLogin"#define node_id_type "nodeId"//This ismy msg TYPE#define Time_type "time "

is still based on the new class Mytempnodetype created earlier, we create a new method ontimemsg in this class, in which we implement a message response event that gets the time.

classMytempnodetype: PublicKhala::tempnodetype { Public: Mytempnodetype (); Virtual~Mytempnodetype ();
overriding Devtype response events for TempnodetypeVirtual BOOLOndevtypemsg (khala::infonodeptr& infonodeptr, json::value&msg, Khala::timestamp time) {std::stringDevtype = infonodeptr->Getnodetype (); Infonodeptr->send ("This is my devtype:"+devtype); return true; }
New Time Response EventVirtual BOOLOntimemsg (khala::infonodeptr& infonodeptr, json::value&msg, Khala::timestamp time) {std::stringTimestr =Khala::timestamp::now (). toformattedstring (); Infonodeptr->send ("Curr Time:"+timestr); return true; }
Message Registration MethodVirtual voidSetregistermsg (khala::registerhandler&handler) {
Call the Setregistermsg method of the parent class khala::tempnodetype::setregistermsg (handler);
Register Time Response Event Handler.setregistermsg (Time_type,boost::bind (&mytempnodetype::ontimemsg, This, _1, _2, _3)); }};

While we implement the New Method Ontimemsg (), which acquires time, the system does not know the existence of this method, it is necessary to rewrite the message registration method Setregistermsg (), and to complete the registration of the newly created Ontimemsg method in this method.

Before overriding the Setregistermsg method, you must display the Setregistermsg method that calls the parent class, or you will lose the message response event registered by the parent class, that is, login, Devtpye, and the default implementation of the original Tempnodetype class cannot be recognized. IsLogin and other message events.

Finally, we also register our newly created Mytempnodetype class with Nodeserver.settempnodetypeinstance (&mytempnodetype) in the main function.

At this point we have created a new temporary device type message event time. We run the new server-side program and start the test with the client program (./example/testclient/hellokhalaclient2.py) That added the time event:

At this point, we get the system time through the event of the Times message without logging in.

At the same time we notice that although we have rewritten the Tempnodetype class, the IsLogin message event that the original Tempnodetype implemented by default can still be responded to by our request. If you are interested, what happens when you try to override the Setregistermsg method without displaying the Setregistermsg () method that calls the parent class?

We can continue to request time message events after logging in, and still get the system times. Our newly created time message event is unrelated to the login, and any connection can request this message response, which is consistent with our previous definition of the temporary device type message.

4. Temporary Device Type Message Event