2010-10-27 14 views
10

Abbiamo un sito e abbiamo sviluppato un sistema di chat utilizzando la libreria strophe.js e il server XMPP ejabberd. Usiamo l'allegato di sessione che è stato avviato con PHP (utilizzando una libreria interna). Quello che facciamo è ottenere il RID e il SID dallo script PHP, quindi utilizzare l'allegato alla sessione di strophe. Il suddetto RID e SID sono memorizzati su un cookie e il valore RID sul cookie viene aggiornato ogni aggiornamento del RID su strophe.js. (In questo modo riusciamo a riutilizzare l'ID di sessione all'aggiornamento/navigazione della pagina in altri punti del sito)Web chat XMPP: come risolvere più schede/finestre?

Ora pianifichiamo di farlo funzionare su più schede/finestre. Ho osservato l'implementazione di Facebook e per ogni scheda è presente una lunga richiesta di polling su un determinato dominio. Questo dominio è diverso per ogni scheda. Ad esempio, la scheda uno sarebbe 0.86.channel.facebook.com. La seconda scheda sarebbe 1.86.channel.facebook.com. A quanto mi risulta, risolverà la limitazione del browser di 2 richieste attive a un determinato dominio. Come viene implementata questa soluzione per più domini?

Avanti sarebbe nelle sessioni di chat stessa. Le sessioni di chat sarebbero diverse per scheda, giusto? Come sarebbe sincronizzata l'interfaccia utente con ogni scheda come Facebook? La mia idea è, per ogni azione, che un messaggio venga inviato al JID dell'utente contenente l'azione eseguita relativa alla chat. Ad esempio, l'apertura di una finestra di chat avrebbe mandato un messaggio di righe come questa:

<message from="my_own_jid" to="my_own_jid" type="chat"> 
    <body>{"jid-of-contact":"open-chat-box"}</body> 
</message> 

e questo sarebbe preso sul client di chat e l'interfaccia utente sarebbe stato modificato di conseguenza (in questo caso, l'apertura di una finestra di chat per un contatto).

Eventuali suggerimenti/commenti su questa implementazione?

Grazie!

+0

Su più domini: un dominio diverso potrebbe semplicemente essere una richiesta di reindirizzamento da domini diversi sul server XMPP che utilizzano. Potrebbe essere solo un "travestimento" dal lato del browser. In termini di come accedere alla stessa risorsa con un singolo nome utente, hmm, mi chiedo se FB ha implementato/modificato il server XMPP che usano per ottenere questo. Sarebbe interessante sapere. – DashK

+0

Per mantenere l'aspetto dell'interfaccia utente in più schede: mi chiedo se è possibile utilizzare l'archivio dati di HTML5 per mantenere lo "stato" della chat e avere ogni scheda solo ... risposta agli aggiornamenti nell'archivio dati? In base alle specifiche XMPP, dovresti essere in grado di utilizzare la priorità delle risorse per "controllare" dove verranno inviate le stanze dei messaggi. Mi chiedo se puoi sfruttarlo per ottenere il tuo effetto tabulazione multiplo ... – DashK

+0

@DashKAre accedono alla stessa risorsa? Penso che sia una sessione diversa e ognuna con una risorsa diversa. In questo modo non è necessario modificare il server XMPP (e fare più log in per lo stesso utente con la stessa risorsa è contro lo standard XMPP, giusto?). – putolaruan

risposta

8

Io e il mio team stavamo lavorando allo stesso identico problema - solo che usiamo Openfire invece di Ejabberd (principalmente perché abbiamo competenze Java ma non abbiamo familiarità con Erlang). La nostra azienda sta costruendo browsergames.

La nostra soluzione è composta da:

  • XMPPHP - per prebinding
  • Strophe.js - per la sessione di fissaggio (modificato)
  • Punjab - come Connection Manager (esteso, modificato)
  • Openfire - come server XMPP

Usiamo il punjab, perché l'implementazione BOSH di Openfire non sembra funzionare molto bene con gli altri componenti all'inizio.

Fondamentalmente abbiamo deciso di non creare una sessione per ogni scheda. Ciò è dovuto al fatto che alcuni dei nostri giochi funzionano come i soliti siti Web: un clic su un collegamento richiederà una nuova pagina completa (mentre i nuovi giochi funzionano completamente in ajax e la maggior parte della GUI rimane la stessa). Quindi, in altre parole: la nostra chat basata sul web dovrà funzionare in ambienti in cui l'utente "si sposta sul sito web". Una sessione per una scheda significherebbe una nuova sessione per ogni richiesta di pagina, che sembra un enorme sovraccarico, perché i giocatori spesso cliccano abbastanza velocemente. Quindi - volevamo creare una sessione e attenerci a un giocatore.

Per risolvere che noi - come te - modificato strophe.js per leggere/salvare il RID in un cookie, quindi tutte le schede conoscono il RID corrente e incrementano ad un valore corretto. Un'altra cosa è che abbiamo fatto in modo che Strophe aggiungesse un CID al corpo delle stanze XMPP. CID come ID cliente. Spiegherò l'uso presto ..

Successivamente il piano era di modificare due cose nel punjab. Per prima cosa abbiamo aggiunto una classe che sostituiva il solito modo in cui le richieste di attesa sono archiviate nel punjab. Le richieste BOSH in attesa vengono ora salvate in un dizionario con la CID (che strophe.js ora aggiunge al corpo di ogni richiesta) come chiave. Quando arriva un'altra richiesta dalla stessa scheda, punjab conosce la richiesta di attesa a cui inviare una risposta vuota. Se ci sono nuove stanze da consegnare, il punjab le invierà a tutte le richieste in attesa nel dizionario. Quindi un messaggio in arrivo viene distribuito a tutte le schede. In secondo luogo, abbiamo aggiunto alcune righe, in modo che un messaggio che è stato inviato da una scheda venga immediatamente restituito a tutte le altre schede. Quindi il messaggio può apparire anche nella cronologia delle altre schede.

Ovviamente ci sono altri problemi che devono essere affrontati, come non perdere la cronologia della chat nella GUI quando il giocatore passa alla schermata successiva. Conservare questo in un cookie sarebbe negativo, dal momento che tutte queste cose vengono inviate con ogni richiesta e causano molto traffico. Per questo pensiamo di implementare qualcosa che sia simile all'archiviazione dei messaggi XEP-0136.

Quindi, per dirla in poche parole, abbiamo dovuto trattare con patch/estendere strophe.js e punjab e stiamo modificando un po 'gli standard. Ma per ora funziona bene e sono entusiasta di vedere come funzionerà questa configurazione nella versione beta.

+0

Sono curioso, come sono andate le cose in Beta? Lo chiedo perché sto per imbarcarmi in una soluzione simile. –

+1

Le tue modifiche a strophe/punjab su Github sono casualmente? – Aeon

+0

Sono anche curioso di questo. Puoi condividere la modifica che hai fatto su Strophe e Punjab? –

3

La mia soluzione:

Ogni scheda ha la propria connessione su risorse diverse, tutte con priorità 1.

In openfire Aggiungi server variabili route.all-resources: true
I messaggi saranno trasmessi a tutte le risorse.

Problemi correlati