You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Part of #6853. In the new web rtc mechanism different events trigger a health check if a web rtc connection is established. The more often a channel is used, the more often it will get health checked. Thus increases the likelihood of having healthy web rtc connections for peers which use it often.
Occasions to check
After coming online: A peer which comes online is responsible to open web rtc channels to the peers it shares a Raiden channel with.
After a open channel event arrives: If a new channel is opened either peer should health check the rtc channel with the peer.
At each message attempt: Whenever a peer wants to send a message to its peer, it has metadata available. It prefers to send it via web rtc. It should do the health check upon receiving the request.
Location for the check
Through the RaidenService object the transport module is easily reachable in the entire codebase. Thinking of the general workflow of External Event -> State Change -> Raiden Event -> Action in i.e. transport it could completely be bypassed and already be triggered as soon as we have the necessary information to do so. As a health check doesn't hurt much, can be done in it's own greenlet and is supposed to check often used connections, IMO it should not wait for being processed through the state machine.
What is to be done?
We need to locate all places where we want to health check web rtc connections. We need metadata for it. It might be the case that we need to fetch them explicitly, on other occasions they might already be there. For sending a message we fetch, or receive metadata already anyway.
After coming online, we need to fetch them explicitly. Allowing to fetch a set of address metadata will simplify the process.
After having the metadata in place, we can call raiden_service.transport.health_check_web_rtc() to trigger the process.
Note: if a channel is healthy this is just a synchronous check. If not a channel creation process should be triggered and spawned in its own greenlet.
The text was updated successfully, but these errors were encountered:
Part of #6853. In the new web rtc mechanism different events trigger a health check if a web rtc connection is established. The more often a channel is used, the more often it will get health checked. Thus increases the likelihood of having healthy web rtc connections for peers which use it often.
Occasions to check
Location for the check
Through the
RaidenService
object the transport module is easily reachable in the entire codebase. Thinking of the general workflow ofExternal Event -> State Change -> Raiden Event -> Action in i.e. transport
it could completely be bypassed and already be triggered as soon as we have the necessary information to do so. As a health check doesn't hurt much, can be done in it's own greenlet and is supposed to check often used connections, IMO it should not wait for being processed through the state machine.What is to be done?
We need to locate all places where we want to health check web rtc connections. We need metadata for it. It might be the case that we need to fetch them explicitly, on other occasions they might already be there. For sending a message we fetch, or receive metadata already anyway.
After coming online, we need to fetch them explicitly. Allowing to fetch a set of address metadata will simplify the process.
After having the metadata in place, we can call
raiden_service.transport.health_check_web_rtc()
to trigger the process.Note: if a channel is healthy this is just a synchronous check. If not a channel creation process should be triggered and spawned in its own greenlet.
The text was updated successfully, but these errors were encountered: