Dans quel ordre les messages de chat doivent-ils être affichés?
C'est une question plus profonde que cette question .
Lorsqu'un message de discussion est envoyé dans un système décentralisé, plusieurs événements se produisent consécutivement. Si un message est envoyé via un serveur de routage, comme dans Facebook Messenger ou Slack ou la plupart des autres systèmes de messagerie, ces choses se produisent dans cet ordre:
- Le message est généré (l'utilisateur appuie sur "envoyer")
- Le message est envoyé à un serveur.
- Le message est transmis par le serveur au destinataire.
- Le message est vu par le destinataire.
De plus, ces choses se produisent, entrelacées avec ce qui précède:
- L'expéditeur apprend du serveur que le serveur a reçu le message.
- L'expéditeur apprend du serveur que le destinataire a reçu le message.
- L'expéditeur apprend du serveur que le destinataire a vu le message.
Il y a beaucoup d'incertitude dans l'ordre de ces événements, et il peut y avoir des minutes, des heures ou même des jours entre eux.
Messenger donne à l'utilisateur quelques commentaires en montrant
- un cicle bleu quand 1 s'est produit (mais pas 7)
- un cercle bleu avec une coche bleue lorsque 7 s'est produit
- un point bleu avec une coche blanche lorsque 8 est arrivé
- la photo de profil du destinataire lorsque 9 est arrivé
De plus, l'ordre de plusieurs messages sur plusieurs appareils est incertain. Nous pouvons utiliser des techniques comme les horloges vectorielles pour comprendre un ordre partiel, mais un ordre total est impossible à trouver. Cela devient encore plus difficile lorsque les horloges des utilisateurs sont définies de manière incorrecte ou lorsque les messages sont envoyés, mais mettent une heure à atteindre un serveur, peut-être parce que l'utilisateur a perdu la couverture de la tour de téléphonie cellulaire.
Cette question comporte deux parties:
Quand est-ce que nous horodatons les messages?
- Lorsqu'ils sont générés sur un appareil local, ce qui signifie que l'heure peut être très incorrecte car l'horloge locale est mal réglée.
- Lorsque le message atteint le premier serveur, ce qui signifie qu'il peut être désactivé par des heures ou des jours à compter de l'envoi du message.
- Lorsque le message est reçu par chaque destinataire, ce qui signifie qu'il peut différer d'un appareil à l'autre.
- Pas du tout, ce qui signifie qu'il n'y a pas d'horodatage pour les messages, ce qui rend difficile de voir si un message a été envoyé il y a des semaines ou juste maintenant, mais aussi que ce problème devient beaucoup plus facile.
Deuxièmement, dans quel ordre les messages doivent-ils être affichés?
- Dans l'ordre des horodatages, cependant, ils sont décidés.
- Dans l'ordre des horloges vectorielles, ce qui garantit que certaines choses se sont produites avant d'autres choses. Les liens d'horloge vectorielle seraient résolus par des horodatages.
L'ordre des messages par horodatage signifie que les messages peuvent se faufiler dans l'historique des discussions quelques minutes ou semaines plus tard, si l'horodatage est généré sur le périphérique de l'utilisateur ou si le message est coincé sur un serveur quelque part. Ordonner les choses par horloges vectorielles signifie que les messages de commande affichés à l'écran peuvent ne pas correspondre à leurs horodatages.
Je veux vos réflexions du point de vue de l'expérience utilisateur. Il existe d'autres points de vue importants, tels que la sécurité, les performances et l'exactitude mathématique, mais je ne veux pas de commentaires de ces points de vue pour le moment.
Je recommande fortement deux choses pour préserver la santé mentale des utilisateurs:
Affichez toujours les messages dans le même ordre à tous les participants d'une conversation.
N'essayez jamais de filtrer les messages d'une manière qui puisse les filtrer différemment selon les différents participants à une conversation.
Cela dit, je recommande que l'ordre soit, dans la mesure du possible, l'ordre dans lequel les messages ont été reçus par un serveur central. Vous pouvez annoter les messages avec l'heure à laquelle ils ont été envoyés, si vous le souhaitez.
La raison principale de ces règles est d'empêcher les situations intentionnelles ou accidentelles dans lesquelles les participants comprennent différemment le déroulement d'une conversation.
La source de facto de l'horodatage de vérité est l'heure UTC du serveur.
Le problème est que les appareils clients ne sont pas toujours en ligne - parfois, un mobile n'a ni WiFi ni réseau, donc les demandes sont mises en file d'attente. En outre, les clients peuvent tempérer avec le temps de leur appareil.
Par expérience, il n'y a aucun moyen de s'assurer que les clients ne tempèrent pas avec le temps de leur appareil, alors qu'il est hors ligne. Mais c'est le meilleur que nous ayons pu trouver, pour un système qui dépendait d'un minutage précis des événements utilisateur (les utilisateurs signalent le début et la fin du travail):
- Lorsqu'un utilisateur effectue une action, celle-ci est horodatée à l'aide de l'horloge du périphérique client.
- Une tentative est ensuite effectuée pour envoyer au serveur, avec un autre (demande) horodatage (client) ajouté à chaque tentative.
- Si le périphérique est en ligne et que le serveur l'obtient, le serveur détermine le delta entre la demande et l'horodatage d'origine et le déduit du serveur UTC.
Une surpuissance complète pour la plupart des scénarios, si vous me demandez, mais j'espère que cela vous aidera.