How can an Add-on receive signals/events from outside?

Add-ons Development
#1

Hi all,
is there a possibility for an add-on to receive signals/events from ‘somewhere in the internet’?

Background:
Think of a service several instances of my add-on interact with (could e.g. be a DLT system like ethereum).
The add-on can connect (e.g. via web socket - the endpoint of the service is known) and request the execution of a service (e.g. post a transaction to be executed in the DLT system).
Execution is asynchronous and may take some time.
After a while, the execution is done (e.g. transaction made it in the block) and the add-on needs to know.

A bad solution would be to poll the service provider (or e.g. search the mined blocks) for the add-on to recognize.

A better solution (e.g. implemented for ethereum /solidity) are events the service provider issues when the service was done.

My question now is: how could the add-on receive a message/signal/event from the service provider?

I so far could not solve this.
I can connect via webSocket to the service provider, but opening this communication channel is necessarily unidirectional as we need an endpoint, and nowadays a certifcate for secure communication.
The opened channel times out (at least for me relatively quickly (10s no answer from service provider)- any hints appreciated) and it probably makes no sense to keep a channel open for lets say 30minutes.
Once closed, the service provider can not send a message (e.g. service done) to the app.

Any hints how to solve this without letting the add-on poll?

Thx
Alex

#2

For the “unidirectional” communication there’s also https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events

But if you want bidirectional “real-time” communication you’ll want to keep your websocket alive.

#3

Hi Martin,
I had a read into SSE and it seems comparable to the websocket from the connection point of view:
the client opens the connection and it needs to be held open all the time.
As it is unidirectional, as you alredy pointed out - it seems to make more sense to keep the websocket connection up.

I’m currently facing

The connection to wss://127.0.0.1:8080/ was interrupted while the page was loading.

in situations the server does not send the response within some seconds.
Is there an automatic ping/pong between the server/client in websockets or do I need to send some pings regularly from the server to the client to keep the connection up?

PS:
Im now thinking about a design where the client on connection sends a unique ID.
And on the server side keeping a list of to be sent messages to that ID plus a map from id to current wesocket connection.
In case the connection gets lost and the client reconnects we can still send the messages after reconnection.

This however is like reinventing the wheel; ZMQ and others have implemented all these features; its a bit of a shame that we don’t have any comparable stuff for add-ons

#4

I would say it’s your server who’s killing the connection. For example, NGINX by default kills websocket after 60 seconds:
http://nginx.org/en/docs/http/websocket.html
(last paragraph)

You can also send dummy beacon messages every X seconds to let server know you are still there (but sending it every 9 seconds sounds too much).