12/04/2013 20:57:18
Capito grazie :D. Però mi sembra strano che possa usare soltanto i cron job. Magari ci sta un listener che s'imposta nel php.ini ... boh , mi farò un giro per la rete e vedere se ci stanno anche altre possibilità, se trovo qualcosa vi faccio sapere.
12/04/2013 23:09:40
Un'altra soluzione esiste, non migliora molto il problema delle tempistiche ma toglie di mezzo la necessità di doverti costruire un garbage collector per le sessioni non chiuse con un cron job.
Il problema che stai cercando di risolvere tu qui è la conseguenza di un altro "problema" nascosto a livello più basso nel design del tuo sito:
stai gestendo la sessione degli utenti con due sistemi differenti.
Il primo sistema è il meccanismo sessioni di PHP che si occupa di collegarsi con il browser e associarlo a un'insieme di dati dentro all'array $_SESSION. Il secondo sistema è la tabella nel tuo database che tiene traccia di chi c'è online.
Il problema sta nel fatto che questi due sistemi non sono sincronizzati, quando la sessione PHP scade non c'è modo per dire alla sessione nel DB di cancellarsi.
Cosa succederebbe se invece tu potessi unire questi due sistemi in un sistema unico e fare in modo che quando la sessione PHP scade il record nel db sparisca in automatico? Spostare tutto completamente sul db, così che tu abbia più controllo sui dati di sessione.
PHP offre la possibilità di personalizzare il gestore della sessione con la funzione: session_set_save_handler http://it2.php.net/manual/en/function.session-set-save-handler.php ↗
è molto semplice: devi solo scrivere le funzioni per creare, cancellare, leggere e scrivere i dati nel database e passarle alla funzione qui sopra.
No, questo sistema non risolve completamente il problema che gli utenti non scompaiono quando chiudono il browser, infatti la gestione sessioni di PHP lavora anche lei con un intervallo di tempo che man mano invalida i dati di sessione, perciò ci sarà sempre e comunque un periodo di tempo in cui l'utente risulterà online quando in realtà non lo è.
Allora dov'è il vantaggio nell'usare questo sistema? Il vantaggio sta nel fatto che ora hai un unico sistema per gestire la sessione, e quindi non hai più bisogno di costruire un sistema che pulisca le sessioni rimaste aperte (niente cron, niente richiamare una funzione di pulizia a ogni esecuzione o cose del genere) perchè se ne occuperà php internamente a richiamare le funzioni che tu gli hai fornito.
(Il sistema interno di PHP è comunque molto simile all'eseguire una funzione ogni esecuzione, ma viene fatto in modo statistico e quasi trasparente per te, che quindi non dovrai più occuparti di progettare un ulteriore sistema di manutenzione della sessione dato che ne esiste già uno)
12/04/2013 23:24:57
Do un'occhiata a questa soluzione :). Comunque il problema non è quello di far scomparire l'utente immediatamente anche senza aver cliccato sul Logout, ma evitare di fare pooling su query tutto qui :).
Vediamo se questa soluzione con MYSQL andrà bene :).
12/04/2013 23:49:12
Beh i cicli di cancellazione delle sessioni scadute avvengono in modo statistico. Puoi controllare la probabilità di esecuzione con un paio di direttive in php.ini, di default la probabilità è di un millesimo se non ricordo male. Se hai accesso a quelle variabili puoi controllare quanto spesso (statisticamente) parte il garbage collector, e adattarlo alla grandezza del tuo sito, così da non avere un peso sul db troppo spesso.
13/04/2013 10:54:53
Cronjobs: esistono proprio per questo tipo di operazioni.
Tuttavia, nel caso non si disponesse della possibilità di usufruirne, puoi crearne una versione spartana con un workaround sicuramente non elegantissimo ma funzionale.
1. Nel momento in cui un utente qualsiasi ti lancia l'aggiornamento su tutti, memorizzi il timestamp ( funzione time() di php ) in un file di testo, avendo cura di impostare un lock esclusivo sull'operazione ( puoi fare tutto in un unica istruzione con file_put_contents() ).
2. At this point, ogni singolo utente verifica l'esistenza del file e si carica il timestamp che esso contiene in sessione (in questo modo eviti di chiamare più del dovuto il file testuale in lettura).
3. Ad ogni refresh di un utente verificherai quindi che il tempo attuale sottratto del tempo memorizzato in sessione non sia maggiore di 600 secondi (10 minuti).
4. Quando passano i famosi 600 secondi il primo utente che giunge lancerà la procedura di controllo su tutti ( la funzione ignore_user_abort() può esserti estremamente d'aiuto ).
A questo punto la logica riparte dal punto 1.
Puoi semplificare tutto il processo in una singola funzione, così fai un singolo richiamo in cima ad un eventuale front controller pattern ed hai risolto.
Have Fun!
13/04/2013 14:07:33
13/04/2013 21:10:42
21/04/2013 02:28:21
Ciao Ragazzi:)
Sto implementando le due logiche per gli utenti online. Sia quella col Database che quella del file di testo proposto da blancks.
Per quanto riguarda la seconda soluzione non ho capito una cosuccia. Allora, salgo il timestamp nel file di testo e in sessione il time, in modo tale che quando implemento il pooling nn vado a caricare il file di testo ma a leggere il time in sessione. Se verifico che è passato tanto tempo allora faccio un update su tutti gli utenti. La mia domanda però è questa.
Per ogni utente, che fa qualcosa sul gdr, vado ad aggiornargli il timestamp relativo alla sua utenza?
Grazie ancora dell'aiuto :D.
Discussione seguita da
Rispondi alla Discussione Aggiungi ai Preferiti Inoltra Discussione Forum Programmazione, GDRCD, Open Source, Hosting Elenco Forum
The Coven: La quest continua...
I dati del generatore di rank sono stati aggiornati!
Football Team Soccer → Diventa una stella del calcio! Crea, allena ed equipaggia il tuo giocatore. Unisciti a un club e vinci in Football Team Game!
Legacy of Magic: Festa della cacciata della Perdizione
Storie di Agarthi: Piccoli ritocchini per enormi Titani
CRSED: F.O.A.D.: Corsa agli zombi!
Il gestore di Le Cronache di Raja Dunia ha risposto alla recensione di derek_ryger
Exclusive Villa GdR → Las Vegas, azzardo, vizi, soldi, intrighi... Più le sue luci sono scintillanti, più le sue ombre sono oscure. La città che non dorme mai, vi aspetta.
Il gestore di Crystal Tokyo ha risposto alla recensione di aryamoon
La Tana del Ladro: TdL Stories - 🌑 Le Maschere Nere 🌑
dalya ha recensito Le Cronache di Raja Dunia
Dark Genesis → Ascendi al cielo in Dark Genesis! Raduna potenti semidei, costruisci il tuo impero volante e scontrati in battaglie divine!
Age of Crystals: Evento Arrivederci Genithalia, Benvenuto Rhotyx IV
RAID Shadow Legends: Contest Grafico!
Enlisted: Foreste del Brandeburgo - Ampliamento della sede
Il portale raggiunge i 16.600 giochi catalogati! Grazie a tutti!
The Coven → Negli scorci di luce delle paludi della Louisiana fioriscono nuove ombre. Estend e la Congrega ti aspettano per vivere emozionanti avventure!
Dal gioco alla scrittura - Quante volte vi è venuta voglia di trasportare un'avventura giocata col vostro personaggio in un racconto? Ecco come farlo in 5 facili step!
Return to Hogwarts - Intervista allo staff del play by forum potteriano Return to Hogwarts!
Processo Creativo - Il processo creativo di J.R.R. Tolkien: dal seme alla foglia
AI e GdR - Abbiamo chiesto a due AI di presentarsi e spiegarci cosa possono fare per i giocatori di ruolo online. Scopriamo cosa ci rispondono!
Nox Venetiae - Recensione del gdr Nox Venetiae ambietato in una oscura Venezia governata dal Doge Mocenigo
Tesi Steampunk - Tesi sulla narrativa steampunk e i suoi problemi di traduzione
Multiplayer - Multiplayer: al tavolo con la tecnologia dei casinò online
Giochi di Calcio - Lista completa dei giochi di ruolo online nel mondo del calcio