[Ninux-Wireless] Pacchetti UDP e rcvfrom
Filippo Sallemi
tonyputi a gmail.com
Sab 24 Lug 2010 12:51:41 CEST
Ciao Nino,
Si ci avevo pensato ma avevo un dubbio circa l'utilizzo di snmp e la sua
configurazione.
La situazione è questa:
Ci sono n nodi collegati lungo tutto il lungo mare ogni 3 nodi c'è un'adsl
da 4 Mb ed infino c'è un server a pochi chilometri con un adsl dedicata che
fa solo monitoring e log dei nodi e del traffico (meshboard/freeradius).
Con questo voglio dire che i nodi non sono in lan con il server, quindi è
possibile utilizzare snmp su questo scenario senza installare VPN? Se si
avreste qualche doc che spieghi come configurare nodi e server?
P.S. La rete al mare sta riuscuotendo un notevole succcesso, dunque per
ringraziare la comunità del supporto sarei ben felice di mettere un link a
ninux sul sito dell'associazione.
Ciao
Il giorno 24 luglio 2010 10.19, Nino <nino a ninux.org> ha scritto:
> 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.anselmi a 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 <tonyputi a 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 <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:
> >>>
> >>> 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.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
> >>
> >_______________________________________________
> >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
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://ml.ninux.org/pipermail/wireless/attachments/20100724/dc17ec8b/attachment-0001.html>
Maggiori informazioni sulla lista
Wireless