[Ninux-Wireless] Pacchetti UDP e rcvfrom
Nino
nino a ninux.org
Sab 24 Lug 2010 10:19:05 CEST
Sembra il lavoro perfetto per le trap snmp.
Filippo, ci avevi pensato?
Se succede qualcosa al nodo, ti avverte immediatamente e a quel punto puoi fare il poll snmp.
Ovviamente quello che non fanno e` rilevare la caduta completa di un nodo, ma per esempio dovrebbero essere in grado di indicarti anche un calo di tenzione dell`alomentazione etc...
Forse sarebbe la soluzione piu` standard per avvicinarsi al vero monitoring.
Ciao
Nino
Antonio Anselmi <tony.anselmi a gmail.com> ha scritto:
>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
>>
>_______________________________________________
>Wireless mailing list
>Wireless a ml.ninux.org
>http://ml.ninux.org/mailman/listinfo/wireless
Maggiori informazioni sulla lista
Wireless