TCP vs Affidabile UDP

Question

Sto scrivendo un'applicazione in cui il lato client sta caricando i dati sul server tramite un collegamento wireless.

La connessione dovrebbe essere molto affidabile. Il collegamento dovrebbe interrompersi molte volte e ci saranno molti client connessi al server.

Sono confuso se utilizzare TCP o UDP affidabile.

Si prega di condividere i vostri pensieri.

Grazie.

Answer 1

RUDP non è, ovviamente, uno standard formale, e non si sa se si troveranno implementazioni esistenti che è possibile utilizzare. Data una scelta tra la compilazione da zero e il rifacimento delle connessioni TCP, avrei scelto TCP.

Answer 2

Per sicurezza, vorrei andare con TCP solo perché è un protocollo affidabile e standard. RUDP ha lo svantaggio di non essere uno standard stabilito (anche se è stato menzionato in diverse discussioni IETF).

Buona fortuna con il tuo progetto!

Answer 3

Se non si è sicuri, le probabilità sono che si dovrebbe usare TCP. Per prima cosa, è sicuro che farà parte dello stack di rete per qualsiasi cosa supporti IP. "Affidabile UDP" è raramente supportato immediatamente, quindi avrai un supporto extra per i tuoi clienti.

Answer 4

È probabile che entrambi i collegamenti TCP e RUDP vengano interrotti dal proprio ambiente, quindi è improbabile che il fatto di utilizzare RUDP sia di aiuto; ci saranno probabilmente momenti in cui nessun datagramma può passare ...

Ciò che è effettivamente necessario assicurarsi è che a) è possibile gestire il numero di client connessi, b) il protocollo dell'applicazione può rilevare ragionevolmente rapidamente quando si hai perso la connettività con un client (o server) ec) puoi gestire la riconnessione richiesta e la manutenzione dello stato della sessione di connessione incrociata per i client.

Finché ci si occupa di b) ec), non importa se la connessione continua a essere interrotta. Assicurati di progettare il tuo protocollo applicativo in modo da poter svolgere le attività in piccoli gruppi; quindi se stai caricando dei file, assicurati di inviare piccoli blocchi e che il protocollo applicativo possa riprendere un trasferimento interrotto a metà; non si vuole ottenere il 99% del percorso attraverso un trasferimento da 2 GB e perdere la connessione e ricominciare.

Per far funzionare correttamente il server è necessario un tipo di cache dello stato della sessione client in cui è possibile mantenere lo stato logico della connessione di un client oltre la durata della connessione stessa. Progettare fin dall'inizio di prevedere che una determinata sessione includa più connessioni separate. Lo stato della sessione dovrebbe avere una sorta di timeout, quindi se il client va via per lungo tempo non continua a consumare risorse sul server ma, per essere onesti, potrebbe semplicemente essere il caso di salvare lo stato su disco dopo un po.

In sintesi, non penso che la scelta del trasporto sia importante e vorrei andare con il TCP almeno all'inizio. Ciò che conta davvero è riuscire a gestire lo stato della sessione del client sul server e gestire il fatto che i client si connetteranno e si disconnetteranno regolarmente.