Newsgroup: it.comp.lang.perl
Titolo: bloccare STDIN

Salve,
     ho uno script che manda un flusso di dari binario verso il mio web 
server. A ricevere questo flusso sul mio web server c'è uno script che 
prende il flusso con <STDIN>. Avevo pensato di mettere nel header HTTP 
una coppia chiave/valore che servisse per identificarsi 
$ENV{"HTTP_USER_PSWD" }e in caso di fallita identificazione di chiudere 
il flusso e uscire dallo script: close STDIN; exit;
Tuttavia ho notato uno strano comportamento, anche se chiudo il socket 
dall'altra parte non casca ma continua a spedire!
ho provato anche a spedire il flusso al seguente script:
use CGI;
$CGI::DISABLE_UPLOADS = 1;
$CGI::POST_MAX        = 512 * 1024;
exit;
ma il flusso continua ad arrivare!! allora nel mio web server ho provato 
a fare: ps ux
USER     PID %CPU %MEM VSZ RSS TTY STAT START  TIME COMMAND 
claudio  531  0.0  0.0   0   0 ?   Z    19:13  0:00 [receiver.cgi] 
<defunct> 
che vuol dire quel <defunct>?? non riesco inoltre a killare questo 
processo...e intanto il server continua a riceve il flusso..
credete che sia un bug del mio web server??
grazie

 grazie
Se usi l' interfaccia CGI direi che e' normale. Non so' dirti pero' che con
php che e'built-in con Apache o con mod_pero o fastCGI se sia la stessa
cosa
perche' non neo ho esperienze.
Nello standard CGI il server HTTP tiene separato il socket verso il client
e il pipe verso il processo CGI che ha lanciato.
L' ho capito in questo modo:
il client chiede di accedere a /cgi-bin/
miacgi.pl
 e il server HTTP sa che
il contenuto sara' prodotto dall esecuzione di tale script, quindi:
Lancia un nuovo processo con cui rimarra' collegato con pipe (pipe + dup2 +
fork + exec) e gli passera' alcuni header suoi + la richiesta del Client.
La CGI iniziera' a produrre l' output sul pipe e il server HTTP validera'
gli header (almeno in Content-type) e iniziera' a trasmettere tutto al
Client appena gli headers sono passati (una linea vuota li separa dal
contenuto)
In questo scenario, se qualcuno si ritira (il client chiude il socket o la
CGI chiude pipe e chiama exit) continuera' a sostenere l' altra
comunicazione e a dropparne il contenuto, non chiudera' automaticamente
l' altra, credo per carantire la consistenza delle transazioni.
Immagina se una CGI dovesse essere killata dal server HTTP perche' un
client
cha chiuso la connessione: le basi dati potrebbero rimantere in stati
inconsistenti. Per qualche motivo tale comportamento e' tenuto lato client.
Se anche la tua CGI ha chiuso STDIN (che era duplicato con dup2 su in pipe
aperto dal server HTTP prima che venisse lanciata) il socket HTTP di rete
verso il Client rimane attivo e il contenuto continua ad essere ricevuto,
anche se sara' buttato via silenziosamente.
Il fatto che nel frattempo vedi il processo <defunct> e' perche' il server
HTTP non ha ancora chiamato wait() per quel processo. Dipende dal server.
Potrebbe chiamarlo immediatamente alla ricezione di SIGCHLD, ma un server
multiprocesso (fork o prefork) potrebbe anche non farlo (comunque mi sembra
uno schifo). Quando il processo server HTTP chiamera' exit sara' il
processo
numero 1 (init) a chiamare wait per tutti.
Direi che il protocollo CGI ti impedisce di controllare il socket handler
del server HTTP verso il Client. Dovresti usare altri standard o
riscriverti
un server HTTP dove incorpori quelle che attualmente sono CGI.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 client
Per prima cosa grazie per questa spiegazione esauriente. Volevo sapere 
se durante questo sostenere l'altra comunicazione e a dropparne il 
contenuto il server è effetivamente appesantito...in poche parole, 
potrebbero bloccare il mio web server mandandogli svariati MBs di dati? 
con svariate istanze? (immagino cosa potrebbe succedere se molti socket 
si collegano al mio server a qualsiasi file cgi e spedisco flussi di 
dati).
Non avevo mai considerato i CGI sotto questo punto di vista. Devo 
contattare l'amministratore del mio web host?
grazie