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 <[email protected]> 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: > > 1. Usare minor banda possibile; > 2. 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 <[email protected]>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 <[email protected]> >> 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 <[email protected]> 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, <[email protected]> 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 <[email protected]> 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 >> >>> >> [email protected] >> >>> >> http://ml.ninux.org/mailman/listinfo/wireless >> >>> >> >> >>> >> >> >>> > _______________________________________________ >> >>> > Wireless mailing list >> >>> > [email protected] >> >>> > http://ml.ninux.org/mailman/listinfo/wireless >> >>> >> >>> _______________________________________________ >> >>> Wireless mailing list >> >>> [email protected] >> >>> http://ml.ninux.org/mailman/listinfo/wireless >> >> >> >> >> >> >> >> -- >> >> Filippo Sallemi >> >> >> >> _______________________________________________ >> >> Wireless mailing list >> >> [email protected] >> >> http://ml.ninux.org/mailman/listinfo/wireless >> >> >> > >> > >> > _______________________________________________ >> > Wireless mailing list >> > [email protected] >> > http://ml.ninux.org/mailman/listinfo/wireless >> > >> > >> _______________________________________________ >> Wireless mailing list >> [email protected] >> http://ml.ninux.org/mailman/listinfo/wireless >> > > > > -- > Filippo Sallemi > -- Filippo Sallemi
_______________________________________________ Wireless mailing list [email protected] http://ml.ninux.org/mailman/listinfo/wireless
