Rilevazione server UDP - I client devono inviare i multicast per trovare il server o il server deve inviare un beacon regolare?

Question

Ho clienti che devono connettersi tutti a un singolo processo del server. Sto usando la scoperta UDP per i client per trovare il server. Ho il client e il server di scambiare l'indirizzo IP e il numero di porta, in modo che una connessione TCP/IP possa essere stabilita dopo il completamento del rilevamento. In questo modo le dimensioni del pacchetto sono ridotte. Vedo che ciò potrebbe essere fatto in due modi usando UDP:

1. Ogni client invia il proprio messaggio multicast alla ricerca del server, a cui il server risponde. Il client può ripetere l'invio di questo messaggio multicast a intervalli regolari (nel caso in cui il server sia inattivo) finché il server non risponde.
2. Il server invia un messaggio di segnalazione multicast a intervalli regolari. I client si iscrivono al gruppo multicast e in questo modo ricevono il messaggio multicast del server e completano la scoperta.

In 1. se ci sono molti client allora inizialmente ci sarebbero molti messaggi multicast trasmessi (uno da ciascun client). Solo il server si iscriverebbe e riceverebbe i messaggi multicast dai client. Una volta che il server ha risposto al client, il client cessa di inviare il messaggio multicast. Una volta che tutti i client hanno completato la scoperta del server, non vengono trasmessi ulteriori messaggi multicast sulla rete. Se, tuttavia, il server non funziona, ogni client invierà un messaggio di messaggi multicast a intervalli fino a quando il server non verrà ripristinato e potrà rispondere.

In 2. solo il server invia un messaggio di segnalazione multicast a intervalli regolari. Questo messaggio finirebbe per essere indirizzato a tutti i client che sono iscritti al gruppo multicast. Una volta che i client ricevono il pacchetto, il socket di ascolto UDP del client viene chiuso e non vengono più sottoscritti al gruppo multicast. Tuttavia, il server deve continuare a inviare il beacon multicast, in modo che i nuovi client possano scoprirlo. Continuerebbe a inviare il segnale a intervalli regolari, indipendentemente dal fatto che alcuni clienti siano fuori dalla loro richiesta di scoperta o meno.

Quindi, vedo pro e contro in entrambi i casi. Mi sembra che il # 1 provocherebbe inizialmente un carico più pesante, ma questo carico alla fine si riduce a zero. In # 2 il server continuerà a inviare un faro per sempre.

UDP e multicast sono un argomento abbastanza nuovo per me, quindi sono interessato a scoprire quale sarebbe l'approccio preferito e che comporterebbe un carico di rete inferiore.

Answer 1

Vorrei raccomandare il metodo # 2, in quanto è probabile (a seconda dell'applicazione) che si avranno molti più client dei server. Facendo inviare al server un beacon, si invia un solo pacchetto ogni tanto, piuttosto che un pacchetto per ogni client.

L'altro vantaggio di questo metodo è che rende più semplice per i client determinare quando un nuovo server diventa disponibile o quando un server esistente lascia la rete, in quanto non devono mantenere una connessione a ciascuno server, o continua a interrogare ogni server, per scoprirlo.

Answer 2

Entrambi sono metodi ugualmente validi.

L'argomento del metodo n. 1 sarebbe che, in linea di principio, i client avviano le richieste e i server ascoltano e rispondono a tali richieste.

L'argomento per il metodo n. 2 sarebbe che il punto di multicast è così che un host può inviare un pacchetto e può essere ricevuto da molti client (uno-a-molti), quindi è destinato a essere il contrario di # 1.

OK, come penso a questo in realtà sono attratto da # 2, beacon avviato dal server. Il problema con # 1 è che supponiamo che i client trasmettano i beacon e si colleghino con il server, ma il server passa offline o cambia indirizzo IP.

Quando il server esegue il backup e invia il suo primo beacon, tutti i client verranno notificati allo stesso tempo per riconnettersi e l'intero sistema verrà immediatamente ripristinato. Con # 1, tutti i client dovrebbero rendersi conto individualmente che il server è andato, e tutti avrebbero iniziato il multicasting allo stesso tempo, fino a quando non si ricollegheranno con il server. Se avessi 1000 client e 1 server il tuo carico di rete sarebbe letteralmente 1000 volte maggiore del metodo # 2.

So che questi messaggi sono molto probabilmente piccoli, e 1000 pacchetti alla volta non sono nulla per una rete UDP, ma solo dal punto di vista del design 2 è meglio.

Edit: mi sento come sto sviluppando un disturbo della personalità split-qui, ma solo pensiero di un punto forte del perché # 1 sarebbe un vantaggio ... Se avete sempre voluto attuare una sorta di naturale bilanciamento del carico o ridimensionamento con più server, il progetto n. 1 funziona bene per questo. In questo modo il primo server "disponibile" può rispondere al beacon del client e connettersi ad esso, in contrasto con il # 2 in cui tutti i client saltano sul server beaconing.

Answer 3

L'opzione n. 2 ha un grosso limite in quanto presuppone che il server possa comunicare più o meno direttamente con ogni possibile client. A seconda dell'architettura di rete esatta del tuo sistema operativo, questo potrebbe non essere il caso. Ad esempio, potresti dipendere dal fatto che tutti i router e i software VPN e WAN e NAT e qualsiasi altra cosa le persone collegano le reti insieme, possono effettivamente gestire i pacchetti di beacon multicast.

Con il numero 1, si presume che i client possano inviare un pacchetto UDP al server. Questa è un'aspettativa del tutto ragionevole, soprattutto considerando che la prossima cosa che farà il client è creare una connessione TCP allo stesso server.

Se il server va giù e il cliente vuole sapere quando si tratta di back up, essere sicuri da usare exponential backoff altrimenti si prende la rete verso il basso con una tempesta di pacchetti un giorno!

Answer 4

Ho usato l'opzione n. 2 in passato diverse volte. Funziona bene per topologie di rete semplici. Abbiamo visto alcuni problemi di throughput quando i datagrammi UDP hanno superato l'MTU Ethernet risultando in una grande quantità di frammentazione. Il problema più grande che abbiamo visto è che la scoperta multicast si rompe in topologie più grandi poiché molti router sono configurati per bloccare il traffico multicast.

Il issue that Greg alluded to è piuttosto importante da considerare quando si progetta la suite di protocolli. Non appena ci si sposta oltre le semplici topologie di rete, sarà necessario trovare soluzioni per address translation, IP spoofing e un'intera serie di altri problemi relativi al trasferimento dal livello di rilevamento al livello di comunicazioni. La maggior parte di essi deve fare in modo specifico il modo in cui il server si identifica e garantire che l'identificazione sia qualcosa che un cliente può utilizzare.

Se potessi farlo di nuovo (quante volte abbiamo pronunciato questa frase), vorrei cercare meccanismi di scoperta basati su standard che si adattino al conto e inizino a risolvere gli altri problemi della suite di protocolli. L'ultima cosa che vuoi veramente fare è inventare uno schema di scoperta davvero valido che si interrompe la settimana dopo la sua distribuzione a causa di una topologia di rete imprevista. Google service discovery per un elenco di partenza. Personalmente tendo verso DNS-SD ma ci sono molte altre opzioni disponibili.