[Ninux-Wireless] Pacchetti UDP e rcvfrom
Filippo Sallemi
tonyputi a gmail.com
Gio 22 Lug 2010 16:53:57 CEST
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:
>
> 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 <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
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.ninux.org/pipermail/wireless/attachments/20100722/d34f95a5/attachment-0001.html>
Maggiori informazioni sulla lista
Wireless