Scenarios to think about

[dbvcode]

Starting point:

• Relay started
• AB connected to relay
• Client connected to relay

Scenario 1: The Client dies and eventually reconnects.
In this case it has no idea what live data to keep feeding to the Relay/AB so AB is left without data.

Scenario 2: The Relay dies and eventually reconnects.
What should happen now? I would think the Client should stop sending(fetching from the broker) data when it disconnects from the Relay and resume when the relay is back on. But when the Relay is back on, it has no idea of the data that AB wants.

Scenario 3: AB dies and then it's restarted.
In this case it starts fresh and needs no data at all from the start. But the Client is still sending data. Knowing in the Client there is no one to consume the data, it could disconnect all live streams until further needed. Once AB is back, it could resume activity as requested by AB.

I think in case of failure someone has to remember what data is needed. My suggestion is to store this data as an object with a UNIX millisecond timestamp.
When AB wants historic or live data it updates the object/array/whatever structure with the requested data and updates the timestamp.
If the client is connected, it sends the object to the relay. The relay should also store the object. When the Client connects, it then knows what data it should send.
If AB starts fresh, the object is null or whatever with a new timestamp. This gets passed to the relay and to the client(that acts accordingly).
If this would be the approach, then when the relay dies, the client disconnects and stops all broker data fetching. When the relay is back on, it asks AB for the object of the data needed and passes it to the Client that resumes activity.

What do you think?
If anything is not clear I can explain in more detail. Or if there flaws, let me know.

[dbvcode]

I think there should be a queuing mechanism for the commands that come from AB and all requests should be acknowledged when they are done by the client. I think this has to be tightly related to AB's life cycle.

Once wicked scenario it AB doesn't stop but looses connection(internet down) to the relay and client. AB wants data as the user clicks around but nobody knows this as it is not happening live on the relay.

Storing these requests in AB and sending them over to the relay/client when they become available would avoid issues of data missing. On the same note, if the Relay gets all the requests from AB and the client is down those end up in the void.

If the relay stores the requests queue, the client will get it when it connects and start executing those requests, while also sending an ack of some sort to mark them as fulfilled in the queue.

Something along these lines.

[dbvcode]

Hit the wrong close button..

[ideepcoder]

I am aware of many such automation "features" that I will call them; it is a product life cycle.

Automatic Trading Interface is taking up most of the time. that is also C++ for automation of orders

scenario 1: This is Client-App side logic and up to the user.

scenario 2: The reason relay was created was to prevent different drops. There should be a real case that shows Relay abruptly dies.

scenario 3: User clicks backfill all button. AB is designed with user "intervention" philosophy. I can create a Plugin Batch Command. There are a few already added. Remember, for Plugin to be compliant there are many restrictions, it can't access AB, only what is exposed in ADK.

[dbvcode]

With scenario 1 the problem is, while the client is down, AB could request other data that no one will be aware of as there will be no one to listen to that request.

[ideepcoder]

With scenario 1 the problem is, while the client is down, AB could request other data that no one will be aware of as there will be no one to listen to that request.

You have to look as it from A wholistic view.
When you say Down, the underlying cause of down is more important.
If Client is going down, why? If the websocket conn to Broker is down, client should send alerts/notifications.

AB will send signals but whether they are handled or not, how would it matter? because client is down

Scenario 2 & 3: already handled
On the other hand, Client will know if Relay is down as connection will drop.

Client can periodically probe https://github.com/ideepcoder/Rtd_Ws_AB_plugin/blob/main/Docs/WSRTD%20Doc.md#d-get-the-db-status-of-plug-in-database

From AB using batch, Data plugin Command -"DbStatus". I will ask Tomasz if i can use AFL to Data plugin interface.

[ideepcoder]

Added AFL::GetExtraData( "IsrRtdConn" ) that can be used from AFL to check plugin status.
From AB Batch, ine can use "DbStatus" plugin command
AB philosophy is user should control plugin, not the other way around. ( AB compliant plugin )

To-do: Client-app can store state info, like python pickle, and try to reload when restarted.

But the whole goes down thing should have cause.
Relay need not store state.
AB when it restarts, requests bfauto anyway.

Will add the following:
3.1

f) CLIENT-APP connected request ping

{"cmd":"cping","arg":""}

{"cmd":"cping","arg":""}

Get state if any Client-App is connected to the relay.

3.2

b) Ping acknowledgement response

Mandatory code field

{"cmd":"cping","code":200,"arg":"Vendor Connected"}    /* Client running & connected to remote*/
{"cmd":"cping","code":400,"arg":"Vendor Disconnected"} /* Client running but remote source is disconnected*/

If client is not connected, obviously no pong message.