Costruire un servizio di chat non è così facile come penseresti.
Ho creato server, client e SDK XMPP completi e posso testimoniare alcuni dei problemi sottili e difficili che sorgono. Un prototipo in cui gli utenti si vedono e chattano è facile. Un sistema completo di funzionalità con creazione di account, sicurezza, rilevamento, presenza, consegna offline ed elenchi di amici è molto più di una sfida. Ridimensionarlo su un numero arbitrario di server è particolarmente difficile.
PubSub è una funzionalità offerta da Chat Services (vedi XEP-60) piuttosto che un mezzo tradizionale per creare un servizio di chat. Posso vedere il fascino, ma PubSub può avere degli svantaggi.
Alcune domande per te:
-
Lo stai facendo sul Web? Gli utenti si connetteranno e eseguiranno il long-poling o disponi di una soluzione Web Sockets?
-
Quanti utenti? Quante connessioni per utente? Rapporto tra scritture e letture?
-
La tua idea di utilizzare SQS in questo modo è interessante, ma probabilmente non sarà scalabile. Non è insolito avere 50k o più utenti su un server di chat. Se esegui il polling di ciascuna coda SQS per ciascun utente, non ti avvicinerai a questo. Sarebbe meglio avere una coda per ogni server e il server esegue il polling solo di quella coda. Quindi sta a te capire su quale server si trova un utente e inserire il messaggio nella coda giusta.
Sospetto che vorrai fare qualcosa del tipo:
- Un grande database RDS sul back-end.
- Un gruppo di server front-end che gestiscono le connessioni client.
- Alcuni codici Java/C# di livello intermedio che tengono traccia di tutto e instradano i messaggi nel posto giusto.
Per avere un'idea della complessità della creazione di un server di chat, leggere le RFC di XMPP:RFC 3920RFC 3921
