Bien le bonjour, pour une fois c'est a moi de poser une question
 
Donc le but est le suivant: a partir du protocole websocket (via SockJS), je dois avoir un système qui transmet et maintien a jour des sortes de listes a travers plusieurs utilisteurs - le tout en HTML client léger. Les wesocket + un système de room coté serveur est donc la solution la plus évidente.
 
Par rapport a cela, j'ai une contrainte de taille: un utilisateur X, doit recevoir et voir 100% des messages qui transitent entre le serveur et lui.
 
Il me faut donc:
  - un mécanisme de reprise une fois une coupure internet qui survient (ca c'est pas bien dur)
  - un mécanisme capable de savoir, des deux cotés (client ou serveur) si le message envoyé a bien été récupéré par l'autre partie, et si besoin reprendre/redemander des messages précédents si besoin.
 
PS: pour le point 2, il n'y a pas de contraintes de temps.
 
Non pas que je sèche/ou que je sois incapable de faire le 2eme avec mes petites mimines, sachant par exemple que TCP a quelque chose de similaire, j'aimerai savoir si quelqu'un dispose d'un diagramme séquence ou une merde du genre montrant "le best practice" pour cela. L'idée étant qu'a un instant T, les deux parties connectées, puisse chacune avoir la garantie d'avoir tous les messages depuis le connect du client et de quoi reprendre les messages manquant si nécessaire.
 
Sachant que ce que je mets dans les messages est parfaitement libre, donc si je dois par exemple générer un ID unique par message, maintenir des minis jeux de données & co de chaque coté, tout est possible.
 
A vos stylos  

Est-ce que les messages sont stockés dans une BD ?
 
Dans mon appli web Astres (cf ma signature), j'avais mis en place un système de dialogue pour des tickets d'incident entre les différents participants, un dialogue pouvant être adressé à un ou plusieurs destinataires. Pour savoir s'il avait été lu, j'avais mis un flag pour chaque destinataire du message. Si l'utilisateur allais sur la page où se trouvait le message, je considérais qu'il l'avait lu (les messages étaient empilés du plus récent au plus ancien). Mais à l'époque, j'étais passé par du php/html/js (les websockets n'existaient pas).
 
Du reste, du simple ajax ne suffirait pas ?

Etant donné que l'utilisateur doit voir en real time ce qui ce se passe sur la dite liste, nope ajax sert pas a grand chose a part a pooler comme un porc...
 
Ouep tout est stocké en BDD, c'est le but du serveur pour le coup, pouvoir assurer la reprise sur reconnexion

Je vois. Le côté temps réel m'avait échappé.
 
"voir 100% des messages" -> comment tu penses t'assurer qu'un utilisateur a vu (lu ?) un message ? Par acquittement de sa part, où tu considère que si le message est arrivé sur son navigateur, le message est vu ?

Ahh, oui message arrivé sur le navigateur = lu...
 
C'est une problématique de qualité de service only, pas de si un user a lu ou non, s'il n'a pas lu, mais que c'était affiché, c'est pas mon pb
 
 
C'est vraiment purement du:
le mec est sur le tel dans un TGV, ca coupe reprend toutes les 2 minutes, a la fin de son voyage je dois avoir rendu la liste complete de tout ce qui c'est passé pendant son voyage, ca inclus des micro coupures de connexion, ce qu'il y avait pendant les coupures et tous les messages qu'il aurait du avoir durant y compris le renvoi des packets lost sans coupure pour autant...
Je vise une QoS de 100% en gros coté client, soit 100% tant que le serveur tourne ofc...
 
Et mon but c'est de le faire a travers websocket, qui ne gere pas de protocole pour cela -autant que je sache- (en gros tu envois un message = il part, mais tu n'as pas d'idée s'il arrive), le best practice sur ce sujet, c'est ce que je cherche mais pas moyen de trouver
 
Disons que mettre packet lost dans google me ramene a toutes les pages wikipedia de la terre, tres terre a terre avec le TCP... Pas trop ce que je cherche (je cherche plus un diagramme UML ou une merde du genre sur les infos nécessaire que chaque partie doit avoir pour garantir cela de la facon la plus efficace possible)

Pour moi tu ne pourra pas échapper à l'acquittement du client, le serveur réessayant l'envoi du paquet si il ne reçoit pas d’acquittement au bout d'un certain temps.
La période de renvoi du paquet peut-être +/- longue en fonction de la charge prévue côté serveur, avec une période augmentant à chaque erreur, jusqu'à suppression complète du client au bout d'un certain temps.
 
Si tu veux de la réactivité à la reconnexion du client, tu peux rajouter un dépilage des paquets en attente juste après la-dite connexion.
 
Ensuite tu as deux cas:
- Soit il n'est pas acceptable que le client reçoive deux fois le paquet (le traitement d'une réception redondante peut engendrer des erreurs), dans ce cas le client doit savoir si il a déjà traité un paquet ou pas, mais dans tous les cas il doit acquitter
- Soit une réception redondante ne pose pas de problème, dans ce cas une file d'attente par client sur le serveur suffit
 
Enfin tu peux optimiser en fonction des possibilités en réalisant une fusion côté serveur des multiples paquets en attente.
 
C'est comme ça que je fait même si les protocole que j'ai implémentés sur ce modèle ne passent pas par la couche TCP.

De l'UDP ne serait-il pas plus adapté dans ce contexte ?

@rufo: Autant que je sache WebRTC est pas encore super stable, Flash surtout pas; donc non je pense pas que j'ai accès a UDP...
 
Quand bien même, si je dis pas de bétise, UDP cherche justement a autoriser la perte de paquet sans perte de timing (cad un paquet perdu impacte pas le temps de réponse des suivants), et perso, je m'en fou du timing a laquel ca arrive, par contre 0 pertes c'est la base, donc le TCP me va bien!
 
@h3bus: je vais tenter un truc comme ca, j’espérai une espèce de hash magique capable de dire si oui ou non il y a une coupure dans le flot, sans acquittement justement, mais bon, on peut pas tout avoir dans la vie

L'intérêt d'UDP que je voyais dans ton cas, c'était le mode connexion et des datagrammes de longueur variables (dans ton cas, sans doute, un envoi de trame = 1 message). Du coup, soit le message est complètement reçu, soit c'est pas le cas. Y'as pas de cas où des paquets d'un même messages sont reçus mais il en manque...
Après, c'est sûr que si y'a pas de lib dispo actuellement, suffisamment stable pour gérer l'UDP, faut pas te casser la tête

Quand la connexion tcp coupe, elle ne joue plus son rôle de garantie de transmission des données et donc il faut imiter le fonctionnement de la couche tcp : https://fr.wikipedia.org/wiki/Trans [...] quittement Le diagramme de séquence est un va-et-vient client-serveur avant des incrémentations de numéros de séquence.
 
Lorsque l'on récrée la connexion tcp, il faut que le client envoie au serveur une donnée qui permet au serveur de savoir si quelque chose a été raté par le client. Cette donnée peut être un compteur (il faut stocker quelque part et que l'environnement soit concurrent-proof), un timestamp (faire attention à la précision et à la synchronisation des horloges en architecture distribuée), un identifiant unique (permet d'identifier un message précis en bdd). Il est possible de combiner toutes les techniques pour avoir une précision maximum.
 
Le plus simple mais le moins fiable c'est de se baser sur la date seule. On considère que tous ce qui a été envoyé avant le marqueur a été reçu et tous ce qui se trouvent après le marqueur doit être réémis/retransmis. (tcp avant sa coupure ayant garanti la réceptivité et la chronologie des événements) Ca peut suffire si on a quelques messages par minute et que les horloges ne soient pas déréglés.
 
Plus lourd mais probablement plus précis, c'est d'envoyer une liste d'accusé de réception de tous les messages reçus dans la session précédente au moment de la reconnexion.

pourtant avec un ajax côté client, c'est lui qui te demande les infos
donc tu sais quelles infos tu as envoyé, elles sont donc topé en envoyées
ensuite le client reçoit ses infos il va donc te répondre quels recordId d'infos il a reçu
avec sa réponse tu vas pouvoir toper tout les recordId d'infos qu'il a reçu en reçu
 
et forcément il faut mettre une somme de contrôle
tu envois un paquet et somme de contrôle à la fin
comme ça l'ajax récupère un paquet d'info
si la somme de contrôle n'est pas bonne, alors le client va te redemander la même chose