Cosa usi quando hai bisogno di un UDP affidabile?

Se hai una situazione in cui una connessione TCP è potenzialmente troppo lenta e una "connessione" UDP è potenzialmente troppo inaffidabile, cosa usi? Esistono vari protocolli UDP standard affidabili, quali esperienze hai con loro?

Si prega di discutere un protocollo per risposta e se qualcun altro ha già menzionato quello che si utilizza, valutare la possibilità di votarlo e di utilizzare un commento per elaborare se necessario.

Sono interessato alle varie opzioni qui, di cui TCP è a un'estremità della scala e UDP è all'altra. Sono disponibili varie opzioni UDP affidabili e ciascuna porta alcuni elementi di TCP in UDP.

So che spesso TCP è la scelta corretta, ma avere un elenco delle alternative è spesso utile per aiutare a giungere a questa conclusione. Cose come Enet, RUDP, ecc. Che sono costruite su UDP hanno vari pro e contro, le hai usate, quali sono le tue esperienze?

A scanso di equivoci non ci sono più informazioni, questa è una domanda ipotetica e una che speravo avrebbe suscitato un elenco di risposte che dettagliava le varie opzioni e alternative a disposizione di qualcuno che ha bisogno di prendere una decisione.

È difficile rispondere a questa domanda senza alcune informazioni aggiuntive sul dominio del problema. Ad esempio, quale volume di dati stai utilizzando? Quante volte? Qual è la natura dei dati? (es. è un dato unico, una tantum? O è un flusso di dati di esempio? ecc.) Per quale piattaforma stai sviluppando? (es. desktop / server / incorporato) Per determinare cosa intendi per "troppo lento", quale mezzo di rete stai utilizzando?

Ma in termini (molto!) Generali penso che dovrai sforzarti di battere tcp per la velocità, a meno che tu non possa fare alcune supposizioni rigide sui dati che stai cercando di inviare.

Ad esempio, se i dati che stai tentando di inviare sono tali da poter tollerare la perdita di un singolo pacchetto (ad es. Dati campionati regolarmente dove la frequenza di campionamento è molte volte superiore alla larghezza di banda del segnale), allora probabilmente puoi sacrificare una certa affidabilità della trasmissione assicurandosi di poter rilevare la corruzione dei dati (es. attraverso l'uso di un buon crc)

Ma se non puoi tollerare la perdita di un singolo pacchetto, allora dovrai iniziare a introdurre i tipi di tecniche per l'affidabilità che tcp ha già. E, senza impegnarti in una quantità ragionevole di lavoro, potresti scoprire che stai iniziando a costruire quegli elementi in una soluzione per lo spazio utente con tutti i problemi di velocità inerenti.

Che dire di SCTP . È un protocollo standard dell'IETF (RFC 4960)

Ha capacità di chunking che potrebbe aiutare per la velocità.

Aggiornamento: un confronto tra TCP e SCTP mostra che le prestazioni sono confrontabili a meno che non si possano utilizzare due interfacce.

Aggiornamento: un bell'articolo introduttivo .

ENET - http://enet.bespin.org/

Ho lavorato con ENET come protocollo UDP affidabile e ho scritto una versione compatibile con i socket asincroni per un mio cliente che la utilizza nei loro server. Funziona abbastanza bene ma non mi piace l'overhead che il ping peer to peer aggiunge a connessioni altrimenti inattive; quando si hanno molte connessioni, eseguire il ping di tutte regolarmente è molto impegnativo.

ENET offre la possibilità di inviare più "canali" di dati e di rendere i dati inviati inaffidabili, affidabili o in sequenza. Include anche il già citato ping peer to peer che funge da mantenimento in vita.

Abbiamo alcuni clienti del settore della difesa che utilizzano UDT (trasferimento dati basato su UDP) (vedere http://udt.sourceforge.net/ ) e ne sono molto soddisfatti. Vedo che ha anche una licenza BSD amichevole.

RUDP - Protocollo datagramma utente affidabile

Ciò fornisce:

• Riconoscimento dei pacchetti ricevuti
• Windowing e controllo della congestione
• Ritrasmissione di pacchetti persi
• Overbuffering (più veloce dello streaming in tempo reale)

Sembra leggermente più configurabile per quanto riguarda il mantenimento in vita rispetto a ENet ma non ti dà tante opzioni (cioè tutti i dati sono affidabili e sequenziati non solo i bit che decidi dovrebbero essere). Sembra abbastanza semplice da implementare.

Come altri hanno sottolineato, la tua domanda è molto generale e se qualcosa è "più veloce" di TCP dipende molto dal tipo di applicazione.

Il protocollo TCP è generalmente veloce quanto lo è per lo streaming affidabile di dati da un host a un altro. Tuttavia, se la tua applicazione esegue molti piccoli burst di traffico e attende risposte, UDP potrebbe essere più appropriato per ridurre al minimo la latenza.

C'è una facile via di mezzo. L'algoritmo di Nagle è la parte del TCP che aiuta a garantire che il mittente non sovraccarichi il destinatario di un grande flusso di dati, con conseguente congestione e perdita di pacchetti.

Se hai bisogno della consegna affidabile e in ordine di TCP e anche della risposta rapida di UDP e non devi preoccuparti della congestione dall'invio di grandi flussi di dati, puoi disabilitare l'algoritmo di Nagle:

int opt = -1;
if (setsockopt(sock_fd, IPPROTO_TCP, TCP_NODELAY, (char *)&opt, sizeof(opt)))
  printf("Error disabling Nagle's algorithm.\n");

Chiunque decida che l'elenco sopra riportato non è sufficiente e che desidera sviluppare il proprio UDP affidabile dovrebbe assolutamente dare un'occhiata alle specifiche QUIC di Google in quanto copre molti casi d'angolo complicati e potenziali attacchi di negazione del servizio. Non ho ancora giocato con un'implementazione di questo e potresti non volere o aver bisogno di tutto ciò che fornisce, ma vale la pena leggere il documento prima di intraprendere un nuovo progetto UDP "affidabile".

Un buon punto di partenza per QUIC è qui , sul Chromium Blog.

L'attuale documento di progettazione QUIC può essere trovato qui .

Se hai una situazione in cui una connessione TCP è potenzialmente troppo lenta e una "connessione" UDP è potenzialmente troppo inaffidabile, cosa usi? Esistono vari protocolli UDP standard affidabili, quali esperienze hai con loro?

La parola chiave nella tua frase è "potenzialmente". Penso che tu abbia davvero bisogno di dimostrare a te stesso che il TCP è, in effetti, troppo lento per le tue esigenze se hai bisogno di affidabilità nel tuo protocollo.

Se vuoi ottenere affidabilità da UDP, in pratica reimplementerai alcune delle funzionalità di TCP oltre a UDP, il che probabilmente renderà le cose più lente del semplice utilizzo di TCP in primo luogo.

Il protocollo DCCP, standardizzato in RFC 4340 , "Datagram Congestion Control Protocol" potrebbe essere quello che stai cercando.

Sembra implementato in Linux .

Potrebbe essere RFC 5405 , "Linee guida per l'utilizzo di UDP unicast per progettisti di applicazioni" sarà utile per te.

Hai considerato la compressione dei tuoi dati?

Come affermato sopra, non abbiamo informazioni sulla natura esatta del tuo problema, ma la compressione dei dati per trasportarli potrebbe aiutare.

RUDP . Molti server socket per giochi implementano qualcosa di simile.

Il modo migliore per ottenere l'affidabilità utilizzando UDP è costruire l'affidabilità nel programma applicativo stesso (ad esempio, aggiungendo meccanismi di riconoscimento e ritrasmissione)