Créer un service de chat n'est pas aussi simple qu'on pourrait le penser.
J'ai construit des serveurs, des clients et des SDK XMPP complets et je peux témoigner de certains des problèmes subtils et difficiles qui se posent. Un prototype où les utilisateurs se voient et discutent est facile. Un système complet avec création de compte, sécurité, découverte, présence, livraison hors ligne et listes d'amis est beaucoup plus difficile. Ensuite, il est particulièrement difficile de faire évoluer cela sur un nombre arbitraire de serveurs.
PubSub est une fonctionnalité offerte par les services de chat (voir XEP-60) plutôt qu'un moyen traditionnel de créer un service de chat. Je peux voir l'attrait, mais PubSub peut avoir des inconvénients.
Quelques questions pour vous :
-
Faites-vous cela sur le Web? Les utilisateurs vont-ils se connecter et effectuer des déplacements longs ou avez-vous une solution Web Sockets ?
-
Combien d'utilisateurs ? Combien de connexions par utilisateur ? Ratio écritures/lectures ?
-
Votre idée d'utiliser SQS de cette façon est intéressante, mais ne sera probablement pas à l'échelle. Il n'est pas rare d'avoir 50 000 utilisateurs ou plus sur un serveur de chat. Si vous interrogez chaque file d'attente SQS pour chaque utilisateur, vous n'allez pas vous en approcher. Vous feriez mieux d'avoir une file d'attente pour chaque serveur, et le serveur n'interroge que cette file d'attente. Ensuite, c'est à vous de déterminer sur quel serveur se trouve un utilisateur et de placer le message dans la bonne file d'attente.
Je suppose que vous voudrez faire quelque chose comme :
- Une grande base de données RDS sur le backend.
- Un groupe de serveurs frontaux gérant les connexions client.
- Certains codes Java/C# de niveau intermédiaire suivent tout et acheminent les messages au bon endroit.
Pour avoir une idée de la complexité de la construction d'un serveur de chat, lisez les RFC XMPP :RFC 3920RFC 3921
