Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Message delivery issues not being sent or confirmed by receiver #778

Open
tomsmith8 opened this issue Oct 12, 2023 · 6 comments
Open

Message delivery issues not being sent or confirmed by receiver #778

tomsmith8 opened this issue Oct 12, 2023 · 6 comments

Comments

@tomsmith8
Copy link

As per this ticket here some messages are not going through or there is an issue with the confirmation back from the receiver.

Andrew has experienced this with two different lite users.

@tomsmith8 tomsmith8 changed the title Issues with either messages not going through or receiving confirmation from the receiver Message delivery issues not being sent or confirmed by receiver Oct 12, 2023
@uncleJim21
Copy link
Contributor

uncleJim21 commented Oct 13, 2023

One proposal I had was to use checksums on the messageIds array. That way the client and server can easily "ping" each other with a value to determine if a resync is needed with relatively low overhead. What do you think @kevkevinpal?

@uncleJim21
Copy link
Contributor

Here's a very simple prototype I made. The idea is that you could quickly and easily detect a discrepancy in the checksum between the local and remote database and take error correction action if the checksums are not identical:
image

This technique is pretty common in communication systems due to its effectiveness: you only need that one string to determine if there's an error so you can check for errors quite frequently. One way I propose we do it is just have the client & relay compare checksums every N seconds while inside a chat and if there's a discrepancy, initiate a "self healing" routine where it resends any messages on local that are not recognized as sent by the relay.

@Evanfeenstra
Copy link
Contributor

Nice idea... the bigger problem though is that messages might never make it to your relay because of lightning liquidity issues, or MQTT issues

@uncleJim21
Copy link
Contributor

Just so we're clear the chain of custody looks something like

(sender client) --(1)---> (sender relay) ---(2)---> (recipient relay) ----(3)---->(recipient client)

It seems you're mostly concerned about step 2 which seems to be the problem here?

@Evanfeenstra
Copy link
Contributor

Right. Latest relay master waits for step 2 before returning a success or error message to the sender, so that should help a lot with "silent" failed msgs

@uncleJim21
Copy link
Contributor

So are these current failures silent because the relay isn't update to latest master?

One thought for how we can help on the client side is to detect a pattern of frequent failures and make recommendations such as adding more liquidity and alert the user?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants