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!
War Thunder → Aviazione, veicoli corazzati e flotte militari della seconda guerra mondiale. Parteciperai a tutte le principali battaglie!
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
Dark Genesis → Ascendi al cielo in Dark Genesis! Raduna potenti semidei, costruisci il tuo impero volante e scontrati in battaglie divine!
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
Lineage II → Entra in uno sconfinato mondo fantasy dominato da razze in contrasto tra loro. Scatena i tuoi poteri in uno dei Mmo più famosi al mondo!
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!
Enlisted → Guida la tua squadra di soldati in combattimenti su larga scala, con fanteria, veicoli corazzati e aerei della IIa Guerra Mondiale!
FloorPlanner - Scopriamo Floorplanner, l'editor online gratuito per planimetrie da utilizzar nelle tue giocate online!
Olympus Project - Intervista al gestore del GdR PbC fantascientifico Olympus Project!
Statistiche Tecniche 2023 - Gdr-online.com pubblica i dati tecnici dei suoi visitatori per l'anno 2023!
HHPGDR - Intervista alla gestrice del noto play by forum Hogwarts: Harry Potter Gioco di Ruolo!
Attacchi e Difese - Lista degli attacchi e difese possibili in questo breve manuale da tenere sempre a portata di mano!
Les Ombres de Bruges - Recensione del play by chat Les Ombres de Bruges: il gotico moderno!
APP e Abitudini - Le app hanno cambiato le nostre abitudini in tutti i settori!
Sailor Land - Intervista alla gestione di Sailor Land, il play by chat ambientato nell'universo di Sailor Moon!