Multicast e ifconfig

[dusklight82]

Salve a tutti,
vorrei aiuto su una questione che mi sta facendo penare non poco:

Ho un host Linux su cui gira un'applicazione che si sottoscrive ad una serie di gruppi multicast.

Se la scheda di rete viene spenta:

ifdown eth0

e successivamente riaccesa:

ifup eth0

,tutte le sottoscrizioni al multicast vengono perse, pertanto l'applicazione diventa "sorda".

C'è un modo per evitare che questo avvenga (ovvero mantenere le sottoscrizioni anche se la scheda viene spenta) ?

[BTS]

benvenuto nel forum

se non ricordo male il down e l'up è sostanzialmente quello che fa il /etc/init.d/networking restart che quindi cancella tutto quanto e fa ripartire da capo la scheda di rete.


bisognerebbe trovare un modo per salvare le connessioni staticamente in un file e ricrearle dopo il down up

[dusklight82]

Grazie per il benvenuto!!!

E' quello che pensavo, ma non avrei idea di come farlo in modo pulito... la mia esigenza è ricrearle a basso livello e non applicativo

Di fatto dovrei "congelare" le vecchie connessioni e ripristinarle appena la scheda si riaccende.

qualche idea?

[BTS]

prova a fare qualche esempio di queste regole.

chi le crea?
a che servono...


spiega la questione

[dusklight82]

OK ci provo:

su tutti gli host della rete gira questa applicazione che, per comunicare, utilizza gruppi multicast:

224.170.10.3
224.170.11.3
224.170.12.3
224.170.13.3
...


uno degli host viene eletto master mentre gli altri sono slave:

• Il master invia notifiche periodiche della sua presenza.
• Se dopo un timeout un host non riceve notifiche o altre candidature, si candida come master dopo un tempo casuale, inviando l'opportuno messaggio.
• Se dopo un certo tempo non riceve notifiche o altre candidature si designa master ed invia a tutti la notifica.
• se un master sente una notifica da un altro master, retrocede dalla posizione e diventa slave

Tutto funziona bene e l'interazione tra gli host avviene correttamente.
Quando viene spenta la scheda di rete l'host si isola e non "sente" le notifiche, pertanto diventa master lui stesso.
Il resto degli host procedono normalmente con il vecchio master.

Quando la scheda viene riaccesa le sottoscrizioni ai gruppi multicast sono state cancellate, pertanto l'host che si era eletto master durante l'isolamento continua a non sentire notifiche dal vecchio master e non retrocede dalla mastership, inviando a sua volta notifiche.

Il vecchio master riceve notifiche dal nuovo e retrocede a slave.

La rete si configura correttamente dal punto di vista degli slave (compreso il vecchio master), ma il nuovo master è sordo e continua a vedersi isolato.

Vorrei trovare un modo per poter ridurre al minimo il tempo necessario a ristabilire le sottoscrizioni, sostanzialmente salvando automaticamente la situazione subito prima dell'ifdown e ricaricandola subito dopo l'ifup.

Ristabilendo le sottoscrizioni il master tornerebbe a ricevere e quindi la rete si riconfigurerebbe correttamente.

[BTS]

ma queste si impostano nell'applicativo?

[dusklight82]

Si all'avvio dell'applicazione la sottoscrizione ai gruppi multicast avviene passando per uno strato intermedio fornito da ACE TAO.


Il sistema su cui sto lavorando è Red Hat 4.2. con kernel 2.6.9-22

[BTS]

hai provato a creare uno script che faccia:

kill applicazione
ifconfig eth0 down
ifconfig eth0 up
start applicazione


?

[dusklight82]

Vorrei trovare un modo per poter ridurre al minimo il tempo necessario a ristabilire le sottoscrizioni, sostanzialmente salvando automaticamente la situazione subito prima dell'ifdown e ricaricandola subito dopo l'ifup.

Purtroppo non posso riavviare l'applicazione perchè richiede troppo tempo ...
La parte di rete è solo una delle sue funzionalità e le altre devono essere operative anche quando la rete viene disabilitata.

Credo che la strada giusta sia "estrarre" la configurazione dei gruppi dalla scheda e salvarla (su file -probabilemente lento- o in memoria) per poi reinserirla all'ifup.

Ho provato a scrivere un'applicazione "di recupero" che non fa nulla se non ripetere la sottoscrizione al multicast.
Con questo stratagemma il Sistema Operativo non scarta più i pacchetti e i messaggi dell'applicazione principale vengono ricevuti correttamente, anche se i suoi processi non risultano, dal punto di vista del SO sottoscritti ai gruppi.
Il problema in questa soluzione è che, poichè i gruppi sono associati solo al processo di recupero, nel momento in cui questo termina le sottoscrizioni vengono cancellate dal SO e si ritorna alla situazione di sordità.
Lasciando in piedi il recupero, tutto funziona ma, ho cmq un processo in più che resta lì "appeso".

[BTS]

ma allora proviamo a concentrarci sul problema a monte.

perchè mai devi disabilitare la scheda di rete?

[dusklight82]

Per esempio se l'host va in manutenzione:

l'amministatore isola la macchina dalla rete e va ad operare su qualcosa.
Intanto l'applicazione deve restare operativa e, nonappena la rete torna disponibile, ricollegarsi al resto del sistema.

[BTS]

ogni quanto va in manutenzione?

[dusklight82]

all'incirca una volta la settimana... direi

[BTS]

una volta la settimana... l'applicazione ci mette troppo tempo a ripartire, ma nel frattempo funziona tra gli altri server.

non è un tempo accettabile?

[dusklight82]

Purtroppo no... almeno da requisiti.

L'operatività deve essere la massima possibile anche nelle fasi "transitorie" e si richiede di essere robusti verso qualsiasi tipo di "fault" della rete compreso la disattivazione dei servizi per manutenzione.
Effettivamente è una situazione piuttosto stringente e verificherò se è possibile rilassare i requisiti, intanto però vorrei trovare una soluzione, almeno teorica, o un workaround.


P.S.
ti ringrazio molto per il tempo che mi concedi

[BTS]

ma ti dico... se a mano non si possono impostare queste regole (neanche con zebra/quagga?) non puoi far altro che impostarle nell'applicazione.

se neppure lì si può... non c'è soluzione

[dusklight82]

hmmm.... zebra (che conosco un po') o quagga (che non conosco) non li avevo considerati... vedo se posso utilizzarli per ottenere qualcosa di buono.

Direi a questo punto che è necessario riconsiderare i requisiti e vedere se si può fare qualcosa.

Grazie ancora del tempo concesso... se riuscirò a fare qualcosa ti farò sapere.