[Ninux-Wireless] Pacchetti UDP e rcvfrom

Antonio Anselmi tony.anselmi a gmail.com
Gio 22 Lug 2010 17:02:26 CEST


in questo caso credo che sul server ci sia una specie di "tolleranza",
nel senso che se non ricevo beat per n- secondi di fila allora
presumibilmente il nodo e' giu' (una specie di validity time alla
olsr). Altrimenti, al primo beat perso il server potrebbe credere che
il nodo sia a ramengo.

Antonio

Il 22 luglio 2010 16.53, Filippo Sallemi <tonyputi a gmail.com> ha scritto:
> Per completezza, quello che dice Antonio è giusto, ma è utilie nella
> situazione immediatamente successiva, ovvero inviare l'intero stato (o altre
> info) del nodo ad un entità centrale, per cui è necessario essere certi che
> arrivi e magari ricevere una risposta (robin update).
> In generale io vedo come unica informazione del beat, il nodo che lo sta
> mandando e nient'altro.
>
> ovviamente la parte server collezionerà una serie di pacchetti "beat" in
> base ai quali saprà se il nodo c'è oppure no.
>
> Magari mi sbaglio ma a me pare cristallino.
>
> Ciao
>
> Il giorno 22 luglio 2010 16.47, Filippo Sallemi <tonyputi a gmail.com> ha
> scritto:
>>
>> Sono daccordissimo con te Michele, non ho proprio voglia di reinventare
>> l'acqua calda anche se in verità il programmino con il suo ciclo di vita
>> dovrebbe essere abbastanza facile da implementare e con pochi rischi di
>> fallimento.
>>
>> In verità avrei voluto usare snmp per questo genere di cose ma non so se
>> in realtà è la scelta giusta.
>>
>> La scelta di UDP dipende da due fattori:
>>
>> Usare minor banda possibile;
>> Non mi interessa se perdo qualche pacchetto, mi interessa solo dire "hei
>> ci sono" ogni tot secondi, dove tot è un numero veramente basso.
>>
>> Il software è pensato per una serie di applicazioni lato server e
>> sicuramente non è sufficiente per fare monitoring dei nodi, ma rappresenta
>> un inizio...
>>
>> Filippo
>>
>>
>> Il giorno 22 luglio 2010 16.42, Antonio Anselmi <tony.anselmi a gmail.com>
>> ha scritto:
>>>
>>> perche' non usare TCP? con UDP "spari e speri" che il beat arrivi a
>>> destinazione, senza alcuna info sullo stato della connesiione
>>>
>>> Antonio
>>>
>>> Il 22 luglio 2010 14.45, Michele Favara Pedarsi <mfp a meganetwork.org>
>>> ha scritto:
>>> > Di heartbeat ce ne sono a iosa; da semplici script che pingano a
>>> > soluzioni
>>> > complesse. Cerca prima di sviluppare l'ennesima tecnologia apposita...
>>> > anche
>>> > perche' stai facendo un sistema di monitoraggio, e come tale ha bisogno
>>> > di
>>> > essere affidabile; se te lo fai da solo rischi di affidarti ad una cosa
>>> > che
>>> > per essere affidabile deve prima fallire qualche volta per trovare i
>>> > bug...
>>> > a meno che non applichi i modelli di sviluppo piu' rigidi, con i tempi
>>> > che
>>> > questi comportano...
>>> >
>>> > Una via di mezzo potrebbe essere quella di impiegare un qualsiasi
>>> > socket
>>> > server multithreaded generico gia' sviluppato - ie: esente da bachi - a
>>> > cui
>>> > devi aggiungere solo quella pochissima logica che verifica l'arrivo di
>>> > un
>>> > pacchetto ogni x secondi da y IP.
>>> >
>>> > ciao
>>> >
>>> > Michele
>>> >
>>> >
>>> >
>>> > Il giorno 22 luglio 2010 14.37, Filippo Sallemi <tonyputi a gmail.com> ha
>>> > scritto:
>>> >>
>>> >> Vi ringrazio per il supporto ragazzi, ed è tutto molto interessante.
>>> >> Il motivo per cui sto scrivendo questo piccolissimo software è perchè
>>> >> vorrei avere un heartbeat dei nodi da mandare ad un server, per il
>>> >> solo
>>> >> scopo di tenere sotto controllo lo stato dei nodi in tempo più reale
>>> >> possibile ma senza compromettere la banda.
>>> >>
>>> >> In verità penso che sia solo sufficiente mandare un beat al server e
>>> >> non
>>> >> ricvere nulla nel caso specifico, ovviamente però potrei sbaglairmi o
>>> >> non
>>> >> tenere conto di qualcosa che magari mi sfugge.
>>> >>
>>> >> So programmare in concorrenza, ma purtroppo la mia poca esperienza di
>>> >> concorrenza viene da mondo java universitario.
>>> >>
>>> >> Se pensate che quello che sto facendo sia inutile o interesante vi
>>> >> prego
>>> >> di farmelo sapere non voglio reinventare l'acqua calda.
>>> >>
>>> >> Ciao e grazie ancora
>>> >>
>>> >> Il giorno 22 luglio 2010 11.54, <clauz a ninux.org> ha scritto:
>>> >>>
>>> >>> Ciao.
>>> >>> La rcvfrom e' una chiamata bloccante, quindi o usi la sottocitata
>>> >>> select
>>> >>> o entri nel fantastico mondo dei thread e della programmazione
>>> >>> concorrente...
>>> >>>
>>> >>> Clauz
>>> >>>
>>> >>>
>>> >>>
>>> >>> On 07/22/2010 01:54 AM, ZioPRoTo (Saverio Proto) wrote:
>>> >>> > Consiglio questa lettura:
>>> >>> > http://beej.us/guide/bgnet/output/html/multipage/index.html
>>> >>> >
>>> >>> > nello specifico:
>>> >>> >
>>> >>> > http://beej.us/guide/bgnet/output/html/multipage/advanced.html#select
>>> >>> >
>>> >>> > Saverio
>>> >>> >
>>> >>> >
>>> >>> > Il 21 luglio 2010 19.05, Filippo Sallemi <tonyputi a gmail.com> ha
>>> >>> > scritto:
>>> >>> >> Ciao ragazzi,
>>> >>> >> sto giocherellando un po con C e stavo provando a scrivere un
>>> >>> >> piccolo
>>> >>> >> programma che manda pacchetti UDP ad un host solo che ho notato
>>> >>> >> che la
>>> >>> >> funzione rcvfrom resta bloccata finchè il server non manda una
>>> >>> >> risposta
>>> >>> >> anche vuota.
>>> >>> >>
>>> >>> >> Parte del codice esegue questo:
>>> >>> >>
>>> >>> >> read = sendto(sock, str, strlen(str), 0, (struct sockaddr *)&addr,
>>> >>> >> sizeof(addr));
>>> >>> >>         if (read < 0) {
>>> >>> >>             perror("Request error");
>>> >>> >>             return -1;
>>> >>> >>         }
>>> >>> >>
>>> >>> >>         read = recvfrom(sock, buffer, MAXLINE, 0, NULL, NULL);
>>> >>> >>         if (read < 0) {
>>> >>> >>             perror("Read error");
>>> >>> >>             return -1;
>>> >>> >>         }
>>> >>> >>
>>> >>> >>         /**
>>> >>> >>          * Print results
>>> >>> >>          **/
>>> >>> >>         if (read > 0) {
>>> >>> >>             buffer[read]=0;
>>> >>> >>             if (fputs(buffer, stdout) == EOF) {
>>> >>> >>                 perror("fputs error");
>>> >>> >>                 return -1;
>>> >>> >>             }
>>> >>> >>         }
>>> >>> >>
>>> >>> >> Ho provato a usare le fnctl per impostare la socket in modo non
>>> >>> >> bloccante ma
>>> >>> >> ottengo solo l'uscita dal programma e nessun invio di pacchetti.
>>> >>> >>
>>> >>> >> Adesso non è che mi importi tanto avere una risposta dal server e
>>> >>> >> potrei
>>> >>> >> ovviare al problema eliminando la parte di codice dove aspetto
>>> >>> >> risposta, ma
>>> >>> >> la mia curiosità dal punto di vista didattico rimane.
>>> >>> >> Qualcuno saprebbe illuminarmi in qualche modo?
>>> >>> >>
>>> >>> >> Grazie
>>> >>> >>
>>> >>> >> Ciao
>>> >>> >>
>>> >>> >> --
>>> >>> >> Filippo Sallemi
>>> >>> >>
>>> >>> >> _______________________________________________
>>> >>> >> Wireless mailing list
>>> >>> >> Wireless a ml.ninux.org
>>> >>> >> http://ml.ninux.org/mailman/listinfo/wireless
>>> >>> >>
>>> >>> >>
>>> >>> > _______________________________________________
>>> >>> > Wireless mailing list
>>> >>> > Wireless a ml.ninux.org
>>> >>> > http://ml.ninux.org/mailman/listinfo/wireless
>>> >>>
>>> >>> _______________________________________________
>>> >>> Wireless mailing list
>>> >>> Wireless a ml.ninux.org
>>> >>> http://ml.ninux.org/mailman/listinfo/wireless
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Filippo Sallemi
>>> >>
>>> >> _______________________________________________
>>> >> Wireless mailing list
>>> >> Wireless a ml.ninux.org
>>> >> http://ml.ninux.org/mailman/listinfo/wireless
>>> >>
>>> >
>>> >
>>> > _______________________________________________
>>> > Wireless mailing list
>>> > Wireless a ml.ninux.org
>>> > http://ml.ninux.org/mailman/listinfo/wireless
>>> >
>>> >
>>> _______________________________________________
>>> Wireless mailing list
>>> Wireless a ml.ninux.org
>>> http://ml.ninux.org/mailman/listinfo/wireless
>>
>>
>>
>> --
>> Filippo Sallemi
>
>
>
> --
> Filippo Sallemi
>



Maggiori informazioni sulla lista Wireless