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
