Ha senso usare contemporaneamente sia TCP che UDP?

Dopo aver letto UDP è ancora meglio di TCP per i giochi in tempo reale ricchi di dati? , Mi chiedo se abbia senso utilizzare sia TCP che UDP contemporaneamente, ma per cose diverse:

• TCP per l'invio di informazioni inviate di rado, ma che dovrebbero essere garantite per arrivare in modo affidabile.
  Come gli aggiornamenti dei punteggi, il nome di un giocatore o persino lo stato acceso / spento di una luce nel mondo di gioco.

• UDP per la trasmissione di informazioni aggiornate costantemente e che possono essere perse di tanto in tanto, poiché le informazioni più recenti sono sempre in arrivo.
  Come posizione, rotazione, ecc.

È un'idea ragionevole? Quali sono i possibili svantaggi?
Ci sono modi migliori per gestirlo?

Ciò comporta la perdita di pacchetti per UDP a causa della contesa tra i due protocolli - ricorda che UDP non è la consegna garantita, mentre TCP lo è. Più pacchetti TCP supereranno mentre UDP soffre - TCP induce la perdita di pacchetti UDP . C'è stata anche l'idea (storica) che l'infrastruttura del router favorisca TCP su UDP, anche se dubito che sia ancora vero in questa fase avanzata.

Penso che sarebbe meglio trovare uno dei protocolli UDP orientati alla connessione che è là fuori per l'uso in giochi e simili, che offre alcuni dei vantaggi di TCP senza nessuno dei suoi lati negativi. Ce ne sono alcuni, di solito con un white paper che dettaglia ogni concetto.

Un esempio di ciò è la libreria Enet open source , la cui caratteristica principale è la consegna opzionale affidabile e in ordine di pacchetti su UDP.

Ecco una citazione di Sam Jansen da un commento su gafferongames.com :

Parlando come ricercatore di rete e non come sviluppatore di giochi, la conclusione di non usare mai TCP e UDP insieme sembra un po 'forte. TCP avrà perdita di pacchetti solo se sta inviando troppi dati; in qualche modo proprio come i dati UDP che stai inviando. La differenza è che non hai alcun controllo diretto sulla velocità a cui TCP invia, questo ti è nascosto.

Se hai solo bisogno di inviare alcuni dati affidabili e non vuoi preoccuparti della ritrasmissione e dell'implementazione di un protocollo affidabile, e sai che la velocità sarà bassa, allora non ci saranno problemi con l'uso di TCP e UDP.

La relazione non è poi così complessa tra i due in realtà: TCP aumenta semplicemente la sua velocità di invio (se ci sono dati da inviare) fino a quando non ottiene la perdita di pacchetti, nel qual caso ripristina la sua velocità, quindi inizia nuovamente ad aumentare la velocità (questo tempo più lentamente). Quando il suo aumento della frequenza causa la perdita di pacchetti, è molto probabile che colpisca anche qualsiasi altro flusso di dati, inclusi i pacchetti UDP.

Le caratteristiche cartacee della perdita di pacchetti UDP: l'effetto del traffico TCP ha ottenuto i suoi risultati aprendo più connessioni TCP contemporaneamente e inondando la rete di dati. Ciò porta alla congestione seguita dalla sincronizzazione globale , che entrambi causano la caduta dei pacchetti. Ovviamente, un client di gioco non aprirà una dozzina di connessioni contemporaneamente e inonderà la rete di dati, quindi i tuoi risultati saranno diversi.

Per rispondere alla tua domanda:

Mi chiedo se abbia senso utilizzare sia TCP che UDP contemporaneamente, ma per cose diverse [...]

Sì, questa è una cosa accettabile da fare supponendo che tu rimanga entro i limiti della larghezza di banda.

• TCP per l'invio di informazioni inviate di rado, ma che dovrebbero essere garantite per arrivare in modo affidabile. Come gli aggiornamenti dei punteggi, il nome di un giocatore o persino lo stato acceso / spento di una luce nel mondo di gioco.

Quando si utilizzano sia TCP che UDP, si dovrebbe sempre preferire inviare il più possibile su UDP e il meno possibile su TCP.

Ora ti chiedo questo: è davvero necessario inviare il punteggio, il nome del giocatore e lo stato di una luce su TCP? Mentre è vero che alla fine devi ricevere questi dati, è vero che devi ricevere questi dati rigorosamente in ordine ed esattamente una volta?

Probabilmente no.

UDP funziona bene in questi casi e Quake 3 è un buon esempio di come.

Allora, qual è un buon esempio di TCP insieme a UDP? Bene, pensa alla chat di un gioco. Gli aggiornamenti di questa chat (ovvero le nuove righe di testo) devono essere inviati in modo affidabile e rigorosamente in ordine. Pertanto, TCP è adatto.

È un'idea ragionevole?

• sì

Quali sono i possibili svantaggi?

• Perdita di pacchetti, maggiore complessità del codice, un'altra connessione per gestire == maggiori possibilità di disconnessioni, timeout, eccezioni, qualunque cosa ...

Ci sono modi migliori per gestirlo?

• Utilizzare una libreria UDP affidabile esistente. Due dei più popolari sono: Lidgren Network (C #), RakNet (C ++). Per esperienza, posso dire che Lidgren è super facile da usare, veloce e affidabile.

C'è un ulteriore vincolo di risorse da considerare. La maggior parte delle implementazioni (credo tutto, ma non ho alcun riferimento) di TCP sul server ha dei limiti su quante connessioni TCP simultanee può essere aperta contemporaneamente dal server. Ciò limiterebbe il numero di giocatori che puoi aprire contemporaneamente se ogni giocatore ha bisogno della propria connessione.

I limiti sono definiti dalle impostazioni nel sistema di rete. Inoltre ogni connessione consuma un po 'di memoria che deve provenire da qualche parte sul server.

Una soluzione è aprire una connessione TCP temporanea solo mentre i dati vengono trasferiti e chiuderla immediatamente. Questo renderà le transazioni più lente, l'apertura di una connessione tcp è un processo piuttosto "costoso". Come sempre, si tratta di progettare un sistema robusto sin dall'inizio per consentire una grande crescita.