Open yurivict opened 6 years ago
ilovelinux
commented
6 years ago Hmm, if the message has been sent, the client2 must had to receive it. If client2 is offline, the message keep in "pending" state. In other words, the delivery confirmation is also the reception confirmation. I don't think that a message could be lost
iphydf
commented
6 years ago A message can be lost if the target goes offline but the source doesn't know that yet. In that case, you will not get the receipt and eventually you get the friend disconnect event.
I think you can do what you are describing with the current API, but do you have a concrete API in mind that you would need to implement this?
ilovelinux
commented
6 years ago Maybe with UDP? Because as Wikipedia says:
At the lower levels of the protocol stack, due to network congestion, traffic load balancing, or other unpredictable network behaviour, IP packets may be lost, duplicated, or delivered out of order. TCP detects these problems, requests re-transmission of lost data, rearranges out-of-order data and even helps minimize network congestion to reduce the occurrence of the other problems. If the data still remains undelivered, the source is notified of this failure. Once the TCP receiver has reassembled the sequence of octets originally transmitted, it passes them to the receiving application. Thus, TCP abstracts the application's communication from the underlying networking details.
yurivict
commented
6 years ago I think you can do what you are describing with the current API, but do you have a concrete API in mind that you would need to implement this?
This suggestion was inspired by the confusion after one my message was left in a"pending" state and the other side went offline at the same time. I realized that there is no way to tell if it was possibly read or not at all. I have no particular API in mind, except for a trivial one:
unsigned tox_message_sent_count(msgId)
bool tox_message_is_confirmed(msgId)But then this info has to be kept by the client's in DB in case the client itself reboots.
zoff99
commented
6 years ago there is already a spec that solves this and more:
https://github.com/TokTok/c-toxcore/issues/735
TRIfA is using it already. any help implementing it in uTox or qTox welcome.
tox-user
commented
6 years ago TRIfA is using it already. any help implementing it in uTox or qTox welcome.
In order to implement it, we need a branch of TokTok/c-toxcore with message v2. Your fork of toxcore has that, but it also includes a lot of other unrelated changes. Some of us are interested in working on this, but not in your other changes that you've made to your fork (at least I am not at this moment). So the only thing we need is a branch of toxcore with just message v2 related changes and we can start trying to implement it. It would be even better if you could create a PR for it in this repo and get people to review the code, then we would start implementing it, then get people to test it.
tox-user
commented
6 years ago I'm not sure if I understand this problem correctly.
In the case 2 there is a chance that the message was received by the client2
There is a chance, but there is no guarantee. You want to know if your friend received the message. You want to be sure. It's not enough to know that they MAYBE got it. It doesn't tell you anything. Has your friend received your message? Possible answers are:
what is the difference between the two?
A message can be lost if the target goes offline but the source doesn't know that yet. In that case, you will not get the receipt and eventually you get the friend disconnect event.
How can a message get lost? If a client has faux offline messaging, it can't be lost, can it?
yurivict
commented
6 years ago There is a chance, but there is no guarantee.
This is what I want to know. It it says sent=1 acknowledged=0 this means that there is a chance, and if it says sent=0 acknowledged=0 this means there is no chance, and sent=1 acknowledged=1 means a guarantee.
what is the difference between the two?
The probability distribution is distinctly different.
tox-user
commented
6 years ago sent=1 acknowledged=1 means a guarantee
Tox already tells you when that happens. It's the only time when it's 100% sure.
The probability distribution is distinctly different.
So how much of a chance is there? 10%? 50%? Why does it matter? When you send a message to someone, you want to know if they received it or not. Anything in between doesn't make sense here. When it tells you that your friend maybe has received your message, how is that different from no?
yurivict
commented
6 years ago So how much of a chance is there? 10%? 50%? Why does it matter?
It matters for the purpose of estimating chances. For example, the user writes something that he later regrets sending. If the chance of this being actually sent is exactly 0%, the message can be safely deleted. If the chance is >0%, the user has to deal with consequences of sending it. Big difference.
This is just one example.
zoff99
commented
6 years ago @tox-user messages get lost all the time, and faux offline messages dont work. and if they do work sometimes then the date/time is just a random date, and nowhere near when the messages was actually sent/typed
tox-user
commented
6 years ago I don't lose messages in qTox, so I don't know. If that actually happened, Tox would be pretty useless. We've had bugs that broke offline messaging before in qTox, but most or all of them are fixed. What do you mean with the date? In Tox you can see the date of receiving, right? Getting a time of when an "offline" message was sent is a different issue (https://github.com/qTox/qTox/issues/4851).
What you are talking about has nothing to do with this issue, does it? This issue isn't about fixing current problems with messages (like https://github.com/TokTok/c-toxcore/issues/896#issuecomment-392263622), but about adding a way for users to see that someone MAYBE received our message.
tox-user
commented
6 years ago messages get lost all the time
Maybe it has something to do with the way faux offline messaging is implemented in the client you use? In qTox the message will be sent over and over again until it gets a confirmation. Which in rare cases can cause a message to be sent twice, if I remember correctly.
zoff99
commented
6 years ago i use qTox
iacore
commented
4 months ago Hmm, if the message has been sent, the client2 must had to receive it. If client2 is offline, the message keep in "pending" state. In other words, the delivery confirmation is also the reception confirmation. I don't think that a message could be lost
Is this true in toxcore? I want to know that the message is guaranteed to deliver.
zoff99
commented
4 months ago @iacore at the moment with toktok toxcore messages can get lost and also messages can be sent multiple times. both cases have happend with different tox clients (it happend frequently with qtox). and both cases can be reproduced with test programs. there are some fixes like msgV2 and msgV3, both of those are not (yet) merged into toktok
Problem description: The user1 sent a message to the user2, but the user2 went offline at the same time. The message is displayed as "pending". There are two possibilities:
Case 1 and case 2 are fundamentally different (message was possibly read or not read at all), but the message looks the same, in a "pending" state.
Feature suggestion: Add the API that will allow the UI client to display 2 values: how many times a particular message has been sent (an integer), and if the confirmation was received (a boolean). The UI client would be able to display this information to users, so that they will be better informed about the status of individual messages.