Any workaround to send feed/p2p message?
Closed this issue · 9 comments
aboozaid commented
My UI is completely different than serval_chat and it seems that you only know if the feed/message successfully delivered through load all feeds/messages then listen for future ones using runnable thread but what if I want to send without load? at this, I cannot find how to assure it delivered or not and this would make sense to gain better performance.
any thoughts? @lakeman
lakeman commented
Note that sending a message will not return until the message has been
recorded locally. Delivery to the other endpoint could take an arbitrary
length of time, or it might never occur.
One thread reading the global list of new/updated rhizome bundles will tell
you which content has been updated. eg;
https://github.com/servalproject/serval_chat/blob/development/app/src/main/java/org/servalproject/mid/Rhizome.java#L91
Observe that, and you can see when the conversation file has grown due to
the other party replying, or adding a delivery ACK. eg;
https://github.com/servalproject/serval_chat/blob/08ed786b657fe9dbdc1f6193f6b8b39d2aacc4cd/app/src/main/java/org/servalproject/mid/Messaging.java#L86
This is how Serval Chat watches to create notifications for incoming
messages, by reloading the conversation list for that Identity. This
doesn't currently include delivery information, which would probably help.
For now, you can use the sender / recipient pair to re-read the updated
message thread, either backwards from the end until you see a delivered
record, or forwards from the last token you've remembered.
https://github.com/servalproject/serval_chat/blob/development/app/src/main/java/org/servalproject/mid/MessageList.java#L35
eg;
serval.getResultClient().meshmsListMessages(RhizomeListBundle.manifest
.recipient, RhizomeListBundle.manifest.sender);
Then just close that http connection.
…On Mon, 30 Mar 2020 at 06:43, Assem ***@***.***> wrote:
My UI is completely different than serval_chat and it seems that you only
know if the feed/message successfully delivered through load all
feeds/messages then listen for future ones using runnable thread but what
if I want to send without load? at this, I cannot find how to assure it
delivered or not and this would make sense to gain better performance.
any thoughts? @lakeman <https://github.com/lakeman>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#14>, or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEQHXQYO2DJANBCS4FFRYDRJ6TWFANCNFSM4LWDMXGA>
.
aboozaid commented
Thanks for your notes, it really helped. I will leave this issue open to collect all the things related to p2p/feed which may inconvenient or unreliable.
when you send a p2p message to a peer, he may not receive it and you know that by ACK received or not but I couldn't find a way to provide a fallback I mean try to send it again without typing a new one @lakeman I think it makes sense so you don't duplicate a message in a receiver side
lakeman commented
Sending a message doesn't work like your typical client / server
interaction.
The sender appends all of their outgoing messages, for the same recipient,
to a local file. After every file append, the contents are hashed and
signed.
That device is the only node that can append to that file, so we don't have
to worry about merging changes together.
Once you've written your changes to that file, it doesn't make sense to
repeat that step.
The goal of the software is then to replicate that file across other
instances of the app, until it reaches the recipient.
A version of that file will arrive at the recipient, if and only if, every
byte of the file has been replicated, the hash and signature are verified.
Transient network errors, or connectivity issues, can only impact the
replication process. Replication will resume once the network allows.
You can write more outgoing messages to that file, creating a new version
of it. But those messages cannot arrive at the recipient unless the entire
file, including all the older messages, has arrived.
…On Fri, 3 Apr 2020 at 10:46, Assem ***@***.***> wrote:
Thanks for your notes, it really helped. I will leave this issue open to
collect all the things related to p2p/feed which may inconvenient or
unreliable.
when you send a p2p message to a peer, he may not receive it and you know
that by ACK received or not but I couldn't find a way to provide a fallback
I mean try to send it again without typing a new one @lakeman
<https://github.com/lakeman> I think it makes sense so you don't
duplicate a message in a receiver side
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEQHXTZFA6PCJUVGVVGOC3RKUTEPANCNFSM4LWDMXGA>
.
gardners commented
... and there is a mechanism to know when a message has been received by
the other side, as they will send an acknowledgement message in their
message stream to the other party. This is how this is already indicated in
Serval Chat.
Paul.
On Fri, 3 Apr 2020 at 11:27, Jeremy Lakeman <notifications@github.com>
wrote:
… Sending a message doesn't work like your typical client / server
interaction.
The sender appends all of their outgoing messages, for the same recipient,
to a local file. After every file append, the contents are hashed and
signed.
That device is the only node that can append to that file, so we don't have
to worry about merging changes together.
Once you've written your changes to that file, it doesn't make sense to
repeat that step.
The goal of the software is then to replicate that file across other
instances of the app, until it reaches the recipient.
A version of that file will arrive at the recipient, if and only if, every
byte of the file has been replicated, the hash and signature are verified.
Transient network errors, or connectivity issues, can only impact the
replication process. Replication will resume once the network allows.
You can write more outgoing messages to that file, creating a new version
of it. But those messages cannot arrive at the recipient unless the entire
file, including all the older messages, has arrived.
On Fri, 3 Apr 2020 at 10:46, Assem ***@***.***> wrote:
> Thanks for your notes, it really helped. I will leave this issue open to
> collect all the things related to p2p/feed which may inconvenient or
> unreliable.
>
> when you send a p2p message to a peer, he may not receive it and you know
> that by ACK received or not but I couldn't find a way to provide a
fallback
> I mean try to send it again without typing a new one @lakeman
> <https://github.com/lakeman> I think it makes sense so you don't
> duplicate a message in a receiver side
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <
#14 (comment)
>,
> or unsubscribe
> <
https://github.com/notifications/unsubscribe-auth/AAEQHXTZFA6PCJUVGVVGOC3RKUTEPANCNFSM4LWDMXGA
>
> .
>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAFCOT2NODSCCO3E4HQOJ3TRKUYALANCNFSM4LWDMXGA>
.
aboozaid commented
and there is a mechanism to know when a message has been received by the other side, as they will send an acknowledgement message in their message stream to the other party
I already understand this but when a message dropped nothing returned indicating a drop action I mean we can add another action such as MESSAGE_SENT/RECEIVED/ACK/ DROPPED
lakeman commented
There's no such thing as a message being dropped.
If you can see the outgoing message, it has been written into the rhizome
store.
Rhizome will keep trying indefinitely to sync the message everywhere.
If/When the recipient reads the message (this is not quite automatic, one
of the messaging apis must be used), they will create an ACK.
When rhizome syncs the ack back onto your device, you can see that it has
been delivered.
…On Sun, 12 Apr 2020 at 22:50, Assem ***@***.***> wrote:
and there is a mechanism to know when a message has been received by the
other side, as they will send an acknowledgement message in their message
stream to the other party
I already understand this but when a message dropped nothing returned
indicating a drop action I mean we can add another action such as
MESSAGE_SENT/RECEIVED/ACK/ DROPPED
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEQHXTLSF3I42PA3CIENT3RMG5Y7ANCNFSM4LWDMXGA>
.
aboozaid commented
One thread reading the global list of new/updated rhizome bundles will tell you which content has been updated.
MeshMS uses journal bundles as described in serval-dna doc but couldn't find a way to update/delete a message in a bundle (remove it from my local file) I think to delete a dropped message instead of keeping it to be synchronized once again.
lakeman commented
Nope, that is by design.
A journal bundle is only supposed to grow. Once bytes are written, they are
considered immutable.
If one node on the network has a longer file, they have the latest version,
and you should copy theirs.
We exploit that property to sync changes to the file efficiently. We also
exploit that property to reuse the same encryption key.
The encryption process is basically an XOR with a pseudo random bit stream.
If you publish [V1 = A XOR E] & [V2 = B XOR E], then you can calculate [V1
XOR V2 == A XOR B]. Revealing a lot of information about the messages that
have been encrypted.
Breaking that model would require significant changes.
…On Mon, 13 Apr 2020 at 10:20, Assem ***@***.***> wrote:
One thread reading the global list of new/updated rhizome bundles will
tell you which content has been updated.
MeshMS uses journal bundles as described in serval-dna doc but couldn't
find a way to update/delete a message in a bundle (remove it from my local
file) I think to delete a dropped message instead of keeping it to be
synchronized once again.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#14 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAEQHXXV44Y5GDE5JKSR2ZTRMJOVBANCNFSM4LWDMXGA>
.
aboozaid commented
Thanks for clarifying