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.anse...@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 <tonyp...@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 <tonyp...@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.anse...@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 <m...@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 <tonyp...@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, <cl...@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 <tonyp...@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@ml.ninux.org >>>> >>> >> http://ml.ninux.org/mailman/listinfo/wireless >>>> >>> >> >>>> >>> >> >>>> >>> > _______________________________________________ >>>> >>> > Wireless mailing list >>>> >>> > Wireless@ml.ninux.org >>>> >>> > http://ml.ninux.org/mailman/listinfo/wireless >>>> >>> >>>> >>> _______________________________________________ >>>> >>> Wireless mailing list >>>> >>> Wireless@ml.ninux.org >>>> >>> http://ml.ninux.org/mailman/listinfo/wireless >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> Filippo Sallemi >>>> >> >>>> >> _______________________________________________ >>>> >> Wireless mailing list >>>> >> Wireless@ml.ninux.org >>>> >> http://ml.ninux.org/mailman/listinfo/wireless >>>> >> >>>> > >>>> > >>>> > _______________________________________________ >>>> > Wireless mailing list >>>> > Wireless@ml.ninux.org >>>> > http://ml.ninux.org/mailman/listinfo/wireless >>>> > >>>> > >>>> _______________________________________________ >>>> Wireless mailing list >>>> Wireless@ml.ninux.org >>>> http://ml.ninux.org/mailman/listinfo/wireless >>> >>> >>> >>> -- >>> Filippo Sallemi >> >> >> >> -- >> Filippo Sallemi >> >_______________________________________________ >Wireless mailing list >Wireless@ml.ninux.org >http://ml.ninux.org/mailman/listinfo/wireless _______________________________________________ Wireless mailing list Wireless@ml.ninux.org http://ml.ninux.org/mailman/listinfo/wireless
