Bonjour,

Merci d'avance pour votre aide

-
Edité par Ozxlol 2 octobre 2019 à 17:42:57

Bonjour,

Ce n'est pas un socket mais un websocket. Si tu utilise socket.io, il faudra le mettre côté client aussi.

Le plus simple pour voir comment ça marche c'est de faire le tuto "get started", tu comprendras sans doutes un peu mieux : https://socket.io/get-started/chat/ 

piero5673 a écrit:

Bonjour,

Ce n'est pas un socket mais un websocket. Si tu utilise socket.io, il faudra le mettre côté client aussi.

Le plus simple pour voir comment ça marche c'est de faire le tuto "get started", tu comprendras sans doutes un peu mieux : https://socket.io/get-started/chat/ 

Ah génial je ne connaissais pas du tout !

En cherchant je suis également tombé sur Emitter.io, je pense donc faire ton tuto pour comprendre la logique puis passer sur Emitter vu qu'il a l'air de répondre à mon besoin ?

Merci pour ton aide @piero5673

Hum... Bah j'aimerai que le serveur puisse maintenir une connexion temporairement meme dans le cas ou un ou tous les utilisateurs soient déconnectés.

Il vaut donc mieux se positionner sur du Emitter.io afin de stocker les informations dans le "broker" je suppose ?

A toi de voir ce que tu veux niveau librairies, il n'y en a pas vraiment une meilleur que les autres. Emitter.io ne te donne pas la main sur le serveur, si tu dépasse 1Go de données et 50 utilisateur ça deviens payant (pas précisé si c'est par mois, par an ou par session). Une alternative que tu peux mettre en place, c'est Redis, mais il te faut un serveur. Ca reste un peu lourd pour faire l'équivalent d'un chat.

Il faut gérer ça côté client aussi : qu'es-ce qu'il se passe lorsque tu perd ta connexion pour moins d'1 sec, 1 min, ou que tu ne la retrouve jamais, et comment vont réagir les autres clients et ton api.

-
Edité par piero5673 3 octobre 2019 à 15:09:10

Ah je n'avais pas vu les prix pour Emitter.io, un peu fourbe de cacher les prix au fin fond de leur FAQ !

Pour le coup je vais donc utiliser comme tu me l'as conseillé le WebSocket, et puis il y a pas mal de doc et d'infos donc je devrais pouvoir y arriver

Quand tu dis que Radis est un peu lourd pour l'équivalent d'un tchat, tu veux comparer ça a des transferts de médias ? Car en soit un sera un peu plus complexe qu'un chat, mais sans plus...

Bon je n'ai plus qu'à me lancer maintenant. Merci pour tes précieux conseils Piero

Redis, ça peut faire pas mal de trucs mais c'est surtout pour faire du pub/sub. C'est plus lourd à mettre en place et a utiliser que les websocket. Comme tu peux le voir avec socket.io, l'api et le serveur websocket sont en général déployés sur un même serveur, ça fais 2 en 1. Pour faire du pub/sub, tu dois déployer un autre serveur. En pratique, ça sert plutôt a connecter plusieurs serveurs websocket (socket.io gère ça tout seul en plus).

Tu vas peut-être te rendre compte que ton api n'est pas asse puissante toute seule, par exemple il y a trop de clients, ou tu as des taches qui nécessitent pas mal de ressources (genre convertir une vidéo). Le plus simple dans ce cas c'est de déployer plusieurs api. Du coup, tu te retrouve avec plein de serveurs websocket, et ça créer des problèmes parce qu’il n'y a pas de concepts de slave/master avec les serveurs websocket. C'est là que redis interviens : tu peux connecter les serveurs websocket à un serveur redis, et du coup ils peuvent "parler" entre eux via redis.

Le websocket c'est pas très adapté au transfert de médias, même si ça marche en théorie. C'est plutôt pour envoyer des petites string. C'est plutôt l'api qui télécharge le média (cherche multipart formdata si ça t'intéresse), et tu peux utiliser un websocket pour envoyer le lien vers le média une fois qu'il a été téléchargé (ou pour signaler aux autres clients qu'il y a un nouveau média qui vas arriver sur l'api, avec la progression du téléchargement par exemple, ou pour informer le client de l'avancement du traitement si tu convertis une vidéo).