Heartbeat implementation

[zero212]

The problem current problem is master/platform can't recognize a client/node (any match making entities) is still connected or not, also we can't repeatedly sending a register_client msg (or input) from REST to the platform, cuz it will return an exeception.

Hence we need another function where client/node can continuously be monitored by master, via a heartbeat signal/output, which actually work as a watchdog timer, working as follow:

When a client/node is registered, the platform will create an object as a watchdog timer, and start countdown, or create a deadline for the next "client/node still connected" signal, or HeartBeat signal is what we called. And after a set period of time (this time can be dynamic), if the signal is not received, that means the client/node is not connected.

Then the workflow should look like this:

1. Creating another match-making output for HeartBeat signal.
2. Creating a HeartBeat class that master/platform

and more to comes. Can't think of much at this moment :p

[zero212]

small tutorial for people This is the json body

As you can see, we have a new line called heartBeatInterval, this value's unit is millisecond. Function: time until the next heartBeatSignal deadline. If we don't receive any heartBeatSignal in heartBeatInterval ms, then node/client status will be changed to offline

When client or node is offline, they can't be use for matching (for node: ignore offline node, for client: return exception if you try to match an offline client)

To set a client or node status to online, simply send a heartbeat signal and we are cool

Heartbeat signal should look like this: (notice the different in POST command, rest/node/heartbeat and rest/client/heartbeat

There's no console output (via debug module) yet (unless you turn on logback).

And here's how you turn of logback. Go to logback.xml in resources folder, change to

[zero212]

When register a client/node, you will automatically create a watchdog timer for that client/node, and that watchdog will work right away. There's a variable in MatchMakerOutput class where you can define how often (in ms) should the watchDog check for the deadline of heartBeat called watchDogWaitTime.

The default client/node status is online, and default heartbeatInterval is 0. So if you register a client/node without heartBeatInterval, that client/node status will change to offline right away.

[zero212]

please read this before use. @theodorelu27, @juan-castrillon

[alyhasansakr]

@theodorelu27 Could you confirm that the implementation of the heartbeat message is correct? Then we close this issue.

[zero212]

@theodorelu27 if you want I can give you a demo. Contact me via slack

[juan-castrillon]

@zero212 for me is not working right.

The first issue is that when I make the request to /client/get_node/diagnostics_client instead of the server as a JSON i am just getting the id. So instead of

{
   "id":"diagnostics_server",
   "ipAddress":"172.28.144.1:4444",
   "connected":false,
   "resource":0,
   "network":0,
   "location":0,
   "totalResource":0,
   "totalNetwork":0
}

I am getting just

diagnostics_server

And I cannot connect

[zero212]

Oh, i know what's wrong there. I no longer putting the whole JSON body in matchesList. original idea was only put clientID - nodeID. Not JSON body. Because when adding those JSON bodies to the matchlist, that info maybe right for that exact moment but not if the node data's change after that

So if we want to get the info (JSON body), we should have a separate command.

@juan-castrillon

[juan-castrillon]

I see 🤔

An idea would be to store the EdgeNode objects in the list, that way you can update it (is just a pointer) and the one in the list would change, and you could also have access to the body (probably by calling toString()) and the id.

But I believe we need the json response. otherwise how do clients connect to servers?

[alyhasansakr]

yes, Juan is right. @zero212 we need this to work right now, then we worry about the design when we refactor the match-making.

[zero212]

@juan-castrillon I will roll back the change where we get the JSON body as return msg for you. Cool?

[juan-castrillon]

Yes sure 👍. Then I can test the heartbeat 😄

[zero212]

@juan-castrillon Done. Let's test it before Theodore join and gang up on me :))

[theodorelu27]

@zero212 sorry, I just had the time to review, when the application is running normally, the registration and heartbeat works as intended from my side the JSON body problem that @juan-castrillon addressed has also been resolved

There were some things I want to confirm and some interesting stuff:

• what is the connected value that the node needed to pass to the master during registration? Does it refer to connected in master-node relationship or node-client relationship? Because if I set it as false, matchmaking would always fail
• If I registered clientbefore the node, when I tried to use assign_node , it would return this exception otherwise, assign_node work as intended
• After clientand nodewere connected, if I turned off the client, I would receive this exception which I find a bit confusing, given that it is the client instead of the node that is missing Reconnection is possible as long as disconnect_client weren't run
• If I disconnect then try to reassign node, I also received this exception

and no, I don't want a personal demo, please write a stub for your wiki content so we can all confirm the information together

cc: @alyhasansakr

[zero212]

@theodorelu27

• Connected value is rather depreciated, just don't care about it, always set it to true when register clients and nodes.

• You must register all nodes before clients, no other choice. Think like it's a real-life scenario where we set up all the hardware/antenna/node first and then clients appear later

• I fixed that exception in the new push. Should be fine now

[alyhasansakr]

@zero212 I don't understand the point about registering all nodes before clients. Both nodes and clients must be autonomous regardless of the state of the others.

[zero212]

@alyhasansakr Yeah i understand it's not necessarily to be done that way, but because of the way I create history database for clients, I only generate the hashmap of client's history score once when client is registered back when I first implement the score base

This can be fixed if required. I just have to create a new hashmap everytime we register something new.

[alyhasansakr]

@zero212 We should figure this one out later (when we refactor match-making), for now we just leave it as it is.

[theodorelu27]

@zero212 okay, I've tested on my side and it looks good so far, good job @alyhasansakr alright, I'd take it into account when testing in near future