Chat dans application Android et iOS avec serveur PHP

a marqué ce sujet comme résolu.
Auteur du sujet

Bonsoir,

Je cherche actuellement à faire un chat dans les applications (Android et iOS) de mon dernier projet mais je ne sais pas par où commencer et comment faire ! Les seuls contraintes que j’ai : compatible avec PHP (le serveur), compatible avec Java et Swift et adaptable (sécurité bien évidemment aussi).

Bien évidemment, si j’écris ici c’est que j’ai déjà fais des recherches :p

  • Les solutions toutes faites comme Télégram semblaient parfaites (j’ai trouvé que Télégram d’ailleurs comme API gratuite de chat…). Cependant Télégram nécessite une authentification obligatoirement par SMS. C’est un point qui m’empêche de prendre cette solution car cela nécessiterai de demander le numéro de téléphone de l’utilisateur et ce n’est pas prévu !
  • J’ai commencé par regarder les protocoles de communications entre les différents supports (entre les applications et le serveur). D’après mes recherches, les deux moyens les plus utilisés sont le HTTP ou le XMPP. L’avantage du XMPP est qu’il est "presque" spécialement conçu pour communiquer entre plusieurs supports : latence réduite, faible consommation de batterie, asynchrone… Déjà, comment cela est possible que le XMPP consomme moins que le HTTP alors que la connexion est maintenu sur le long terme ? Enfin d’après 90% des sites et certaines vidéos de démonstration, le bon choix à faire est le XMPP.
  • J’ai suivi avec des recherches sur le XMPP avec PHP. J’ai trouvé quelque tutoriels intéressants comme https://www.ibm.com/developerworks/xml/tutorials/x-realtimeXMPPtut/ ou encore des librairies comme https://github.com/fabiang/xmpp mais il faut vraiment tout faire depuis le début (même les services de réceptions des messages etc) et je n’aurai jamais le temps… (ce n’est pas de la flemmardise mais du réalisme!)
  • J’ai ensuite vu la solution Google Cloud Messaging qui semble rapide et efficace mais je n’ai pas tout saisi. En effet, il y a une connexion XMPP entre les téléphones et le serveur de Google et la connexion entre le serveur de Google et mon serveur PHP peut se faire soit en HTTP soit en XMPP. Imaginons que je suis A et que je veux écrire à B et C. A envoie un message au serveur de Google qui doit l’envoyer au serveur PHP qui lui enverra le message à B et C. Donc si le lien entre Google et mon serveur est en HTTP on perd tout l’intérêt du XMPP entre le portable et le serveur de Google… L’autre problème, c’est que je ne vois pas comment à partir d’une librairie comme https://github.com/fabiang/xmpp on peut utiliser la solution de Google ? Les exemples de codes $channel->setTo('channelname@conference.myjabber.com') ->setPassword('channelpassword') ->setNickName('mynick'); ne sont pas du tout adapté à ce cas d’utilisation on dirait… J’ai regardé d’autres librairies comme https://github.com/carlosCharz/FCMTest/blob/master/app/src/main/java/com/wedevol/fcmtest/MainActivity.java mais elle n’a pas été mise à jour depuis longtemps et ne correspond plus. Ce n’est pas forcément un problème, avec un peu de temps je dois peut-être pouvoir adapter le code. Mais avant de m’y mettre je voudrais avoir votre avis sur la chose !

J’espère que j’ai été un minimum compréhensible. Il faut dire que c’est un peu confus dans mon esprit aussi et c’est pour ça que j’aimerai avoir des avis de connaisseurs !

Merci d’avance pour votre aide :)

Si tu as un peu de temps, n’hésite pas à faire un p’tit tour pour voir mon projet ZONNY

+0 -0

Cette réponse a aidé l’auteur du sujet

Telegram est pourri niveau sécurité/privacy, et ils utilisent un protocole "custom".

Si tu veux un protocole propre pour du chat "sécurisé", Signal est ouvert et il existe un bon paquet d’implémentations.

Il existe sinon 2 solutions adaptées à du RTC:

  • MQTT
  • WebSocket

MQTT est le plus adapté, suivant un modèle pub/sub, WebSocket est beaucoup plus "bas-niveau" basique, donc même s’il peut remplir le travail, tu auras pas mal de boulot.

PHP n’est pas adapté au RTC, il suit plus un modèle de traitement simple de requête "fire and forget".

Des systèmes comme python async ou ruby mqtt sont plus adaptés à la maintenance d’une connexion continue.

+1 -0
Auteur du sujet

Merci pour ta réponse et tes pistes de recherches ;)

J’ai regardé du côté de signal mais à part les techniques de chiffrements et des articles théoriques de communication je n’ai pas trouvé grand chose… Enfin rien de techniquement utilisable rapidement !

En effet c’est ce qu’il me faisait peur avec le PHP, cet aspect "fire and forget" comme tu dis. Mais finalement, PHP gère tout cela très bien ! Entre les callbacks http://php.net/manual/en/language.types.callable.php et le fait de pouvoir ouvrir une connexion socket http://php.net/manual/fr/function.stream-socket-client.php on s’y retrouve.

Choisissant la facilité, je me suis tourné vers Firebase. Bon encore une fois c’est Google mais leur système de communication entre les applications, Firebase Cloud Messaging et le serveur PHP est très bien fait et rapide à mettre en place. Lien pour les intéressés : https://firebase.google.com/docs/cloud-messaging/xmpp-server-ref

J’ai donc passé la journée d’hier à mettre en place un script PHP qui permet une connexion XMPP entre le serveur de Google le serveur PHP. Cela permet ainsi de "upstream" aussi des messages depuis les applications (contrairement au HTTP qui "downstream" seulement des messages du serveur PHP aux applications).

Cependant j’ai toujours deux petites questions lors du downstream :

1. A veut envoyer un message à B et C. Par le biais de la connexion XMPP le message de A arrive au serveur PHP. Le serveur PHP doit maintenant envoyer le message à B et C. Mais deux solutions sont possibles :

  • en HTTP. Il y a possibilité de faire une requête HTTP seulement pour l’envoyer à B et C.
  • en XMPP. Il n’y a pas de possibilité de faire une requête groupé. Il faut donc faire deux requêtes séparées.

Le HTTP a donc l’avantage de faire une requête de moins que le XMPP mais le XMPP a l’avantage lui d’avoir une connexion déjà ouverte. Quelle est la solution qui risque de créer le mois de latence possible entre A, B et C ?

2. La deuxième question est à peu près identique. Il s’agit du même problème. Mais cette fois la question se pose entre un requête HTTP et deux requêtes XMPP alors que la connexion n’est pas encore ouverte. Cela implique donc d’ouvrir la connexion XMPP, d’envoyer les requêtes et de fermer la connexion ensuite.

Downstream (source: https://github.com/carlosCharz/fcmxmppserver)

Merci d’avance pour votre aide précieuse :)

Si tu as un peu de temps, n’hésite pas à faire un p’tit tour pour voir mon projet ZONNY

+0 -0

Si tu veux faire une requête de ton serveur vers le client, il faut obligatoirement que ton client soit un serveur HTTP ouvert et en écoute, sinon, c’est tout simplement impossible over HTTP, d’où l’intérêt d’un two-way system comme MQTT ou WebSocket.

+0 -0
Auteur du sujet

C’est justement un point important qui m’a poussé à utiliser Firebase également. C’est que Google gère le système de connexion entre le client et le serveur de Google (Google Cloud Messaging sur l’image dans le précédent post) Lien du site de Firebase pour les intéressés : https://firebase.google.com/docs/cloud-messaging/android/receive#override-onmessagereceived. Cela permet d’avoir une solution optimisée et peu gourmande en batterie. Ainsi le client (smartphone) écoute constamment. Nous, développeurs, n’avons qu’à communiquer entre le serveur de Google et notre serveur. La connexion peut donc être maintenue indéfiniment.

Mes questions étaient plutôt :

  • faut-il par exemple privilégier une seule requête HTTP ou 10 requêtes XMPP avec la connexion déjà établie ?
  • faut-il privilégier une requête HTTP ou 10 requêtes XMPP avec la connexion pas encore établie (besoin d’établir la connexion entre les serveurs avant d’envoyer les 10 requêtes).

Merci pour ton aide ;)

Si tu as un peu de temps, n’hésite pas à faire un p’tit tour pour voir mon projet ZONNY

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte