Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 15
  1. #1

    Verificare se uno socket è attivo

    Ciao,
    mi serve sapere se esiste un metodo di IO::Socket o incluso in perl per sapere se la connessione di uno socket è ancora attivo.

    Uno uno script che usa un IO::Select per verificare le connessioni che mi spediscono pacchetti, ma se questa si è appena sconnessa mi dice che mi spedisce sempre pacchetti, qualche volta vuoti e qualche volta con l'ultimo carattere che ha spedito prima di sconnettersi.

    Esiste una funzione del tipo $sock->status() che mi restituisce lo status della connessione? Io questa funzione non riesco proprio a trovarla.
    Grazie in anticipo.

  2. #2
    Io ho cercato su google newsgroup in cerca della soluzione, ho trovato tanti post ma solo quello che mi interessava era un post senza risposte.
    :°°°°

    Imho, penso non ci sia una soluzione a questo problema.
    Peccato, era intenzionato a fare un bello script a classi e mi devo fermare a questo punto dopo decine di kilobyte scritti di codice.
    Però ora continuo a cercare tra i migliaia di moduli del perl.

    Spero di ricevere quealche risposta perchè non mi piacerebbe sospendere per un problema che pensavo facilmente risolvibile con una semplice funzione.


  3. #3
    http://www.perldoc.com/perl5.6/lib/I...ml#CONSTRUCTOR

    connected
    If the socket is in a connected state the the peer address is returned. If the socket is not in a connected state then undef will be returned.

  4. #4
    ^^
    Bhè grazie, ma quella funzione l'avevo gia provata anche se era quella per avviare la connessione è ritornava il valore solo se veniva effettuata.

    Ho smesso di cercare moduli ed ho trovato una soluzione poco ortodossa, un po' bruttina da guardare.

    codice:
    $stato=0;
    recv($sock, $buf, 2048,0) or $stato=1;
    if ($con || $buf eq "") {
       print "Connessione interrotta.";
       [...]
       $ciao=<stdin>;
    }
    Nell'IF uso due condizioni perchè ho visto che si possono verificare due casi.
    1) Si accorge che il client si è sconnesso e restituisce valore UNDEF cambiando valore di $STATO in 1. Ed esegue il codice nell'IF.
    2) Non si accorge che il client si è sconnesso e non cambia valore a $STATO ma la variabile $var viene rimpeita con caratteri nulli.
    Il codice sopra può essere semplificato in questo modo:
    codice:
    $buf="";
    recv($sock, $buf, 2048,0);
    if ($buf eq "") {
       print "Connessione interrotta.";
       [...]
       $ciao=<stdin>;
    }
    Funzionano entrambi anche se lasciano un po' a desiderare.

    Grazie lo stesso ^^.
    Ciao!

  5. #5
    Vabbe che il mio inglese non e il massimo ma:
    connected: ritorna l'indirizzo del punto se connesso altrimenti undef! :master:

  6. #6
    Originariamente inviato da FreeManX
    Vabbe che il mio inglese non e il massimo ma:
    connected: ritorna l'indirizzo del punto se connesso altrimenti undef! :master:
    Si infatti, anche io quando l'ho provato ed ho visto che non funzionava bene, ci sono rimasto male.
    :/

  7. #7
    Originariamente inviato da LordSaga640
    Si infatti, anche io quando l'ho provato ed ho visto che non funzionava bene, ci sono rimasto male.
    :/
    Cosa intendi che non funzionava bene??

  8. #8
    intendo che se mi connettevo con telnet e poi mi sconnettevo mi dritornava ugualmente gli stessi dati e quindi non potevo controllare l'effettivo stato della connessione.
    CMQ, altri si sono ritovati nella mia stessa situazione senza trovare una soluzione.

    Gia che ci sono, sai come con TK come si crea un form di tipo TEXT dove inserire un campo da tastiera....stavo spulciando tutte le funzioni. penso sia Tk::Text, ora provo ma la pagina delle spegazioni è grande centinaia di kilobyte e rischia di non essere poi la classe giusta :°°°.
    Vabbè, il TK non è un problema perchè almeno so che la classe che cerco esiste sicuramente.
    Mi ha stupito un po' lo socket nella sua inaffidabilità per verificare lo stato della connessione. CMQ, il linguaggio perl per me resta uno dei più flessibili e potenti in giro ed è per questo che l'ho scelto per quello che voglio fare.
    Grazie ancora freemanx, non lo sai, ma mi hai aiutato gia molte volte quando usavo il vecchio nick.
    Quindi, grazie anche per le altre volte (sto parlando di qualche anno fa e forse oltre).
    ciao

  9. #9
    Ciao prego, qui per aiutare!!

    Pero' nella tua soluzione trovo un problemino, la funzione recv e di tipo bloccante (se non sbaglio) cio implica che finche non riceve tutto non esce da se stessa, percui se per qualche problema anche un solo byte non viene perso pe qualche motivo, il tuo programma rimarra li fermo.

    Percui non la trovo molto sicura!

    bye bye

  10. #10
    Bhè, si, in effetti è poco sicura e gestire qualche centinaio di connessione alla volta senza forkare o Threadare è pericoloso.
    CMQ uso un IO::Select che nel momento in cui ricevo dati, lui mi restituisce il file handle da leggere e perciò vado a leggere solo quando riceve dati e spero così di evitare anche il problema della funzione bloccante.

    Stavo solo pensando se era efficente nel stare dietro ai dati. Ossia, pensavo che se spedivo i dati tramite un send o un normale print, lui si può comportare in due modi:
    1) aspettava di averli inviati e una volta fatto continua con il resto di codice.
    2) Oppure li caricava su un buffer e continuava più velocemente con il codice ed aspettava solo se il buffer era pieno.

    Nel primo caso sarei costretto a fare un Thread (opero su piattaforma Win32) che funzioni solo per spedire dati e che abbia un buffer di almeno 4000byte, tanto le connessioni sono binarie e ho intenzione di comprimere i pacchetti con zlib.


    Vabbè, se lo sapete bene, altrimenti pace. Per queste cose strane chiedo sui NG di perl o faccio dei test.

    Grazie, ciao freemanx

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.