Trasmetti come UDP con l'affidabilità di TCP

Question

Sto lavorando a una soluzione .net che venga eseguita completamente all'interno di un'unica rete.Quando gli utenti apportano una modifica al sistema, voglio lanciare un annuncio e fare in modo che tutti gli altri lo ascoltino e agiscano di conseguenza.Esiste un modo in cui possiamo trasmettere messaggi come questo (come UDP ti consente di fare) mantenendo la consegna garantita (come TCP)?

Questo è su una piccola rete (30 client circa), se ciò potesse fare la differenza.

Answer 1

Quasi tutti i giochi necessitano delle proprietà di reazione rapida (e, in misura minore, delle proprietà di assenza di connessione) di UDP e dell'affidabilità di TCP.Quello che fanno è costruire il proprio protocollo affidabile sopra UDP.Ciò dà loro la possibilità di inviare pacchetti semplicemente ovunque e, facoltativamente, renderli anche affidabili.

Il sistema di pacchetti affidabile è solitamente un semplice sistema di tentativi fino alla conferma, più semplice di TCP, ma esistono protocolli che vanno ben oltre ciò che TCP può offrire.

La tua situazione sembra molto semplice.Probabilmente sarai in grado di creare tu stesso la soluzione più pulita: fai semplicemente in modo che ogni client invii una risposta "Ti ho sentito" e chiedi al server di continuare a provare finché non la ottiene (o si arrende).

Se vuoi qualcosa di più, la maggior parte delle librerie di protocolli personalizzati sono in C++, quindi non sono sicuro di quanto ti saranno utili.Tuttavia, la mia conoscenza in questo campo risale a qualche anno fa: forse alcuni protocolli sono già stati trasferiti.Hmm...RakNet ed enet sono due librerie C/C++ che mi vengono in mente.

Answer 2

Dare un'occhiata a scpt che ha una combinazione di funzionalità tcp e udp.C'è una finestra implementazione disponibile.

Answer 3

Potresti usare Diffusione fare comunicazione di gruppo.

Answer 4

@epatel - Appoggio il suggerimento SCTP (ho votato a favore, ma non posso ancora commentare, quindi materiale aggiuntivo qui).

SCTP ha molte ottime funzionalità e flessibilità.Puoi suddividere la tua connessione in più flussi e scegliere l'affidabilità di ciascuno e se è ordinato o meno.In alternativa, con il Parzialmente affidabile estensione, puoi controllare l'affidabilità in base al messaggio.

Answer 5

La trasmissione non è ciò che desideri.Poiché potrebbero e probabilmente ci saranno dispositivi collegati a questa rete a cui non interessa il tuo messaggio, dovresti utilizzare Multicast.A differenza dei messaggi broadcast, che devono essere inviati ed elaborati da ogni client della rete, i messaggi Multicast vengono consegnati solo ai client interessati (cioè quelli che hanno qualche intenzione di ricevere questo particolare tipo di messaggio e agire di conseguenza).

Se in seguito ridimensioni questo sistema in modo che debba essere instradato su una rete di grandi dimensioni, il multicast può adattarsi a questo, mentre la trasmissione no, quindi ottieni un vantaggio di scalabilità che potresti apprezzare in seguito.Nel frattempo elimini i costi inutili negli switch e in altri dispositivi che non hanno bisogno di vedere questi messaggi "qualcosa è cambiato".

Answer 6

Potresti voler esaminare RFC3208 "Specifiche del protocollo di trasporto affidabile PGM" .

Ecco l'estratto:

Pragmatic General Multicast (PGM) è un trasporto multicast affidabile
protocollo per le applicazioni che richiedono ordinate o non ordinate,
Consegna di dati multicast senza duplicati da più fonti a
più ricevitori.PGM garantisce che un ricevitore nel gruppo riceva tutti i pacchetti di dati da trasmissioni e riparazioni o è in grado di rilevare perdita di pacchetti di dati irrealizzabile.PGM è specificamente inteso come soluzione praticabile per applicazioni multicast con requisiti di affidabilità di base.Il suo obiettivo di progettazione centrale è la semplicità di funzionamento con il dovuto riguardo alla scalabilità e all'efficienza della rete.

Answer 7

Potresti utilizzare un Message Broker, ad esempio ActiveMQ.
Pubblica i tuoi messaggi su un argomento e chiedi ai clienti di registrare abbonamenti durevoli all'argomento, in modo che non perdano alcun messaggio anche se non sono online.

Apache ActiveMQ è un broker di messaggi scritto in Java insieme a un client JMS completo.Tuttavia Apache ActiveMQ è progettato per comunicare su una serie di protocolli come stomp e Openwire insieme a supportare una serie di client specifici per linguaggio.

Il supporto della piattaforma client include C# e .net

Answer 8

Potresti implementare il tuo comportamento simile a TCP a livello di applicazione.

Quindi, ad esempio, invierai la trasmissione UDP, ma poi ti aspetteresti una risposta da ciascun host.Se non hai ricevuto una risposta entro X secondi, inviane un'altra e così via fino al raggiungimento di una sorta di soglia.Se la soglia viene raggiunta (es.l'host non ha risposto affatto), quindi segnala un errore.

Per fare ciò, però, avresti bisogno di un elenco predefinito di host da cui aspettarti le risposte.

Answer 9

Creare un server TCP.Chiedi a ciascun client di connettersi.Nel protocollo TCP con i client, crea ciascun pacchetto con un prefisso di 2 byte della dimensione totale del messaggio seguente.

I clienti poi chiamano read(max_size=2) sul socket per determinare la dimensione del messaggio successivo, quindi read(max_size=s) per raccogliere il messaggio.

Ottieni messaggi affidabili, ordinati, semplici.Non è necessario un framework di messaggistica per questo.

Answer 10

Lo faresti decisamente voglio esaminare Multicast generale pragmatico:

Mentre TCP utilizza gli ACK per riconoscere gruppi di pacchetti inviati (qualcosa che sarebbe antieconomico rispetto al multicast), PGM utilizza il concetto di riconoscimenti negativi (NAK).

Per ulteriori G-immersioni, il termine che stai cercando è multicast affidabile.Dai anche un'occhiata a TCP multipercorso.

Answer 11

Quello che puoi fare è che dopo la trasmissione hai il file clienti avviare le connessioni TCP.Altrimenti devi solo tenere un elenco di tutti i client e avviare tu stesso le connessioni con ciascun client.

Answer 12

Penso che ci siano tre opzioni, in generale:

1. Invece di trasmettere UDP, potresti creare un'entità (un thread, un processo, un server, un servizio o qualunque cosa esista nella tua soluzione) che conserva un elenco di abbonati e invia loro messaggi UDP unicast.
2. Utilizza il multicast UDP, ma dovrai scrivere una sorta di meccanismo che si occupi della consegna affidabile per te (ad esempio, nuovi tentativi, timeout, ecc.).Ciò significa anche che devi ricevere una risposta dai tuoi clienti.
3. Se non hai paura dei protocolli di trasporto sperimentali, potresti dare un'occhiata Qui per suggerimenti.,

Answer 13

Yoy dovrebbe dare un'occhiata alle specifiche Norm (NACK-Oriented Reliable Multicast).Potete trovare informazioni su Norm qui.

Il protocollo Norm è progettato per fornire un trasporto end-to-end affidabile di oggetti di dati sfusi o flussi su servizi di routing e inoltro multicast generici.Norm utilizza un meccanismo selettivo di riconoscimento negativo (NACK) per l'affidabilità dei trasporti e offre ulteriori meccanismi di protocollo per condurre sessioni multicast affidabili con coordinamento limitato "a priori" tra mittenti e ricevitori

È piuttosto noto nel mondo militare.

Specifiche della norma.

Fonte della norma

Answer 14

Perché creare qualcosa da zero se puoi usare la libreria?Soprattutto per un progetto così piccolo?

Prova ad usarlo Emcaster che a sua volta utilizza la messaggistica multicast affidabile - PGM, è scritto in .NET e con il codice sorgente completo.Otterrai un bel motore pub/sub con filtro degli argomenti prontamente disponibile.Oppure puoi imparare dal codice come farlo e basare la tua estensione su di esso.

Answer 15

Penso che la caratteristica più irritante del TCP in questi scenari sia la capacità/il modo di ordinare i pacchetti in entrata nel loro ordine originale: il concetto di flusso.Non è possibile leggere un byte finché non arriva il byte prima del suo arrivo.

Se puoi farne a meno, hai la possibilità di avere il tuo protocollo, veloce e affidabile, ma non per ordinare i pacchetti!È semplicemente impossibile gestirli entrambi, perché non puoi ordinare i tuoi byte finché non ricevi un'altra copia di un pacchetto smarrito, questo è il principale compromesso.

Answer 16

eseguire un multicast RDP.