Het bouwen van een chatservice is niet zo eenvoudig als je zou denken.
Ik heb volledige XMPP-servers, clients en SDK's gebouwd en kan getuigen van enkele van de subtiele en moeilijke problemen die zich voordoen. Een prototype waar gebruikers elkaar zien en chatten is eenvoudig. Een systeem met volledige functies met accountcreatie, beveiliging, ontdekking, aanwezigheid, offline levering en vriendenlijsten is een veel grotere uitdaging. Om dat vervolgens over een willekeurig aantal servers te schalen, is bijzonder moeilijk.
PubSub is een functie die wordt aangeboden door Chat Services (zie XEP-60) in plaats van een traditionele manier om een chatservice te bouwen. Ik zie de allure, maar PubSub kan nadelen hebben.
Enkele vragen voor u:
-
Doe je dit via het web? Gaan gebruikers verbinding maken en long-poling of heb je een Web Sockets-oplossing?
-
Hoeveel gebruikers? Hoeveel verbindingen per gebruiker? Verhouding tussen schrijven en lezen?
-
Uw idee om SQS op die manier te gebruiken is interessant, maar zal waarschijnlijk niet schalen. Het is niet ongebruikelijk om 50.000 of meer gebruikers op een chatserver te hebben. Als u elke SQS-wachtrij voor elke gebruiker pollt, komt u daar niet in de buurt. Je zou beter af zijn met een wachtrij voor elke server, en de server peilt alleen die wachtrij. Vervolgens is het aan jou om uit te zoeken op welke server een gebruiker zich bevindt en het bericht in de juiste wachtrij te plaatsen.
Ik vermoed dat je zoiets wilt gaan doen als:
- Een grote RDS-database op de backend.
- Een aantal front-end servers die de clientverbindingen afhandelen.
- Een middelhoge Java-/C#-code die alles volgt en berichten naar de juiste plaats leidt.
Om een idee te krijgen van de complexiteit van het bouwen van een chatserver, lees de XMPP RFC's:RFC 3920RFC 3921