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
