Modificare da programma esterno le variabili in sessione
Alessandro
ho necessit� di passare dei dati elaborati da un mio programma ad una
pagina php (per farla breve).
Attualmente da php faccio delle richieste asincrone via rete ad un
demone (scritto in C) che gira sul server stesso che "elabora" la
richiesta e risponde.
Vorrei invece fare l'inverso e in qualche modo fare un "push" dei valori
dal demone alla pagina php.
Ho gi� testato e messo da parte soluzioni tipo orbited.
Spippolando ho visto che le sessioni non sono altro che file di testo
(scusate l'ignoranza ma io mi occupo solo della parte in C).
In particolare gli array di dati sono schematizzabili come:
...;NomeArray:NumeroRighe:{TipoRiga:Valore;TipoRiga:Valore}....
A questo punto la domanda �: posso editare direttamente il file della
sessione e inserire i valori nell'array manualmente dal demone "C"????
L'architettura finale potrebbe essere una cosa tipo:
1) Viene caricata la pagina php/ajax
2) viene inizializzata la sessione (o ripristinata)
3) viene segnalato al demone l'id della sessione ed il nome dell'array
(magari con una comunicazione via rete)
4) il demone modifica l'array in sessione com'� opportuno quando � opportuno
5) la pagina php si trova "magicamente" le variabili aggiornate
strada lunga? o sbagliata???
grazie a tutti!
Alessandro
Alessandro Pellizzari
> Attualmente da php faccio delle richieste asincrone via rete ad un
> demone (scritto in C) che gira sul server stesso che "elabora" la
> richiesta e risponde.
Abbastanza arzigogolato, non c'e` che dire! ;)
> Vorrei invece fare l'inverso e in qualche modo fare un "push" dei valori
> dal demone alla pagina php.
Che e` la cosa piu` sana da fare.
> Ho già testato e messo da parte soluzioni tipo orbited.
Uh?
> Spippolando ho visto che le sessioni non sono altro che file di testo
> (scusate l'ignoranza ma io mi occupo solo della parte in C).
> A questo punto la domanda è: posso editare direttamente il file della
> sessione e inserire i valori nell'array manualmente dal demone "C"????
No, lascia perdere!
> 1) Viene caricata la pagina php/ajax
> 2) viene inizializzata la sessione (o ripristinata) 3) viene segnalato
> al demone l'id della sessione ed il nome dell'array (magari con una
> comunicazione via rete) 4) il demone modifica l'array in sessione com'è
> opportuno quando è opportuno 5) la pagina php si trova "magicamente" le
> variabili aggiornate
>
> strada lunga? o sbagliata???
A me pare che tu ti stia complicando inutilmente la vita.
Sarebbe stato meglio che tu avessi esposto il problema, invece di una
soluzione.
Immagino che tu abbia un programma in C che genera dei dati e li vuoi
visualizzare da una pagina web.
Se vuoi fare push, ti basta, dal server, richiamare una pagina PHP
tramite curl o sistemi simili, e dalla pagina PHP salvare quei dati da
qualche parte (in DB, in un file, dove vuoi ma NON in sessione).
Dopodiche` avrai una seconda pagina "di frontend" che legge quel file e
visualizza i dati.
Bye.
Omar Dini
quali sono le controindicazioni?
O.
Alessandro Pellizzari
> perche' "NON in sessione"? ..
> quali sono le controindicazioni?
Perche` la sessione, per sua stessa natura, e` una sessione. :)
Cioe` si riferisce a uno stesso "utente" che sta navigando "in quel
momento".
Se tu dal server (quello in C) salvi i dati nella sua sessione, l'utente
che accede dal frontend avra` una sessione diversa (la sua) e non vedra`
i dati del server.
Bye.
Omar Dini
> Perche` la sessione, per sua stessa natura, e` una sessione. :)
> Cioe` si riferisce a uno stesso "utente" che sta navigando "in quel
> momento".
>
> Se tu dal server (quello in C) salvi i dati nella sua sessione, l'utente
> che accede dal frontend avra` una sessione diversa (la sua) e non vedra`
> i dati del server.
>
> Bye.
Il punto e' proprio questo.. Alessandro (l'altro).. se ho capito bene...
vorrebbe salvare i dati direttamente nelle sessioni dei client (che
altro non sono dei file di testo facilmente individuabili una volta che
ha a disposizioni d'id sessione), non fare una propria sessione, in modo
da poter mettere dati diversi per client diversi...
O.
Alessandro Pellizzari
> Il punto e' proprio questo.. Alessandro (l'altro).. se ho capito bene...
> vorrebbe salvare i dati direttamente nelle sessioni dei client (che
> altro non sono dei file di testo facilmente individuabili una volta che
> ha a disposizioni d'id sessione), non fare una propria sessione, in modo
> da poter mettere dati diversi per client diversi...
L'id di sessione viene generato in modo pseudo-casuale ad ogni accesso,
quindi e` praticamente impossibile sapere quale file corrisponde a quale
utente.
Il metodo migliore rimane quello di salvarli da qualche parte. Se vede
discriminare in base all'utente che visualizza la pagina, salvera` una
info aggiuntiva e poi da frontend mostrera` solo le informazioni
riservate a quell'utente.
Ma finche` non chiarisce cosa vuole fare, e` inutile congetturare. :)
Bye.
Gufo Rosso
> Il Thu, 31 Dec 2009 10:30:25 +0100, Omar Dini ha scritto:
>
>> Il punto e' proprio questo.. Alessandro (l'altro).. se ho capito bene...
>> vorrebbe salvare i dati direttamente nelle sessioni dei client (che
cookies ma e' peggio
>> altro non sono dei file di testo facilmente individuabili una volta che
>> ha a disposizioni d'id sessione), non fare una propria sessione, in modo
>> da poter mettere dati diversi per client diversi...
>
> L'id di sessione viene generato in modo pseudo-casuale ad ogni accesso,
> quindi e` praticamente impossibile sapere quale file corrisponde a quale
> utente.
<?php
session_start();
$id = session_id()
$sql = "UPDATE tb_session set session=$id, user = $_SESSION['user']......
Alessandro Pellizzari
> Il 31/12/2009 11.23, Alessandro Pellizzari ha scritto:
>> L'id di sessione viene generato in modo pseudo-casuale ad ogni accesso,
>> quindi e` praticamente impossibile sapere quale file corrisponde a
>> quale utente.
>
> <?php
> session_start();
> $id = session_id()
>
> $sql = "UPDATE tb_session set session=$id, user =
> $_SESSION['user']......
Si`, ma non sai mai se quella sessione e` ancora valida. :)
metti che il server aggiorna i dati a mezzanotte, mentre tutti gli utenti
sono a nanna e le sessioni scadute... ;)
E, visto che hai un database, tanto vale salvare li` le informazioni.
Bye.
DaNieL
>
> E, visto che hai un database, tanto vale salvare li` le informazioni.
>
> Bye.
Già, se l'intento è di non utilizzare un db potrebbe usare APC o
memcached.
Alessandro
no, beh, in questo caso il server (quello in C) modificherebbe
direttamente il file della sessione ed il client si ritroverebbe le
variabili belle e pronte da utilizzare.
altro discorso e' il fatto di comunicare al server quali sessioni sono
state "avviate" (nuove), quali sono attive e quali sono quelle non più
utilizzate. ma questi sono problemetti risolvibili.
tnx,
Alessandro
Alessandro
> On 31 Dic, 15:28, Alessandro Pellizzari<shuri...@amiran.it> wrote:
>>
>> E, visto che hai un database, tanto vale salvare li` le informazioni.
>>
>> Bye.
>
> memcached.
>
dunque... faccio un piccolo riassunto.
il server (quello in C) mantiene aggiornato lo stato di un sistema
(parla con dispositivi, si informa, chiede, fa')
i vari client si connettono e, mettiamo, visualizzano un contatore. ogni
client un contatore diverso (ma anche pi� client lo stesso contatore).
i modi "standard" sono un paio:
1) la pagina php effettua un poll del db per vedere quando c'e' una
variazione del dispositivo che sta visualizzando (ovviamente il server
aggiorner� il db)
2) la pagina php effettua una connessione diretta con il server (quello
in C) e fa' poll direttamente al server
entrambi i sistemi funzionano (ovviamente) ma generano traffico e
aggiungono latenze.
l'idea era di fare "push" dei dati direttamente nelle sessioni per
evitare questo traffico ed avere il sistema pi� reattivo
memcached potrebbe essere una soluzione. tramite libmemcached si pu�
accedere a questa cache e modificarla (dal server C). dal lato php non
c'� problema ad accedere. e' un po' come fare poll del DB, pero'... (e
ci devo ragionare sopra!!!)
tnx
Alessandro
Alessandro Pellizzari
> no, beh, in questo caso il server (quello in C) modificherebbe
> direttamente il file della sessione ed il client si ritroverebbe le
> variabili belle e pronte da utilizzare.
Come ho detto, e` un sistema molto fragile.
E reitero il suggerimento: dal server C richiama una pagina che aggiorna
dei dati in un database.
Se i dati non sono molti, i dati vengono sicuramente cachati in RAM.
A meno che tu non abbia 1000 o piu` accessi al secondo al frontend, anche
una macchina da 400 euro al supermercato ti regge il traffico.
Se, come credo, i client sono un centinaio e aggiornano la pagina ogni
qualche minuto, vai tranquillo.
Bye.
Leonardo Serni
>Ciao newsgroup,
>ho necessit� di passare dei dati elaborati da un mio programma ad una
>pagina php (per farla breve).
Il collo di bottiglia direi che sia comunque la pagina PHP.
Quindi, ti conviene scrivere i dati - magari serializzati usando la stessa
sintassi di PHP - in un file (o un DB, ancora meglio - ma se no un file va
benisssimo) dove il PHP possa trovarli. In AJAX, leggi il file ogni tot da
un timer in Javascript.
-- overkill --
Un sistema ancora piu' elegante e' fare in modo che il demone in C esporti
un socket "querabile"... ma probabilmente e' overkill. Comunque, puoi dare
un'occhiata a "mongoose".
-- extreme overkill --
Se il server e' Linux puoi fare una cosa esagerata come cosi':
- pagina PHP/AJAX lavora in multipart/x-mixed-replace
- server AJAX/PHP che legge da una pipe bloccante (dieci righe di codice)
- il tuo programma scrive i dati sulla pipe
La pagina PHP/AJAX e' un po' pelosa perche' XMLHttpRequest e' schizzinosa,
quando si va ad usare XMR. Dovrai sperimentare un po' con flush() e buffer
vari.
Leonardo
--
The cock doth craw, the day doth daw,
the channerin' worm doth chide:
gin we be mist oot o' oor place,
a sair pain we maun bide.