J'écris une application où le côté client téléchargera des données sur le serveur via une liaison sans fil.
La connexion doit être très fiable. La liaison devrait briser plusieurs fois et il y aura de nombreux clients connectés au serveur.
Je suis confus s'il faut utiliser TCP ou Fiable UDP.
S'il vous plaît partagez vos pensées.
merci.
4 Réponses :
RUDP n'est bien sûr pas une norme formelle, et rien ne dit si vous trouverez des implémentations existantes que vous pouvez utiliser. Compte tenu d'un choix entre le roulant de zéro et la réajustement des connexions TCP, j'aurais choisi TCP.
Pour être sûr, j'irais avec TCP juste parce que c'est un protocole standard fiable. Rudp a l'inconvénient de ne pas être une norme établie (bien que cela ait été mentionné dans plusieurs discussions de l'IETF).
bonne chance avec votre projet!
Si vous n'êtes pas sûr, les chances sont que vous devriez utiliser TCP. D'une part, il est certain de faire partie de la pile de réseau pour tout ce qui supporte la propriété intellectuelle. "UDP fiable" est rarement pris en charge hors de la boîte. Vous aurez donc des travaux de support supplémentaires pour vos clients.
Il est probable que vos liens TCP et RUDP soient brisés par votre environnement, de sorte que le fait que vous utilisiez RUDP est peu susceptible d'aider là-bas; Il y aura probablement des moments où aucun datagramme ne peut passer à travers ...
Qu'est-ce que vous avez réellement besoin de vous assurer que A) Vous pouvez gérer le nombre de clients connectés, B) votre protocole d'application peut détecter raisonnablement rapidement rapidement lorsque vous avez perdu la connectivité avec un client (ou un serveur) et c) vous. Peut gérer la reconnexion et la maintenance requises de l'état de la session de connexion croisée pour les clients.
Tant que vous traitez avec b) et c), cela n'a pas d'importance si la connexion continue d'être cassée. Assurez-vous de concevoir votre protocole d'application afin que vous puissiez faire effectuer les choses en lots courts; Donc, si vous téléchargez des fichiers, assurez-vous que vous envoyez de petits blocs et que le protocole d'application peut reprendre un transfert cassé à mi-chemin; Vous ne voulez pas avoir 99% du chemin à travers un transfert de 2 Go et perdez la connexion et devez recommencer.
Pour que cela fonctionne, votre serveur nécessite une sorte de cache d'état de session client où vous pouvez garder l'état logique de la connexion d'un client au-delà de la vie de la connexion elle-même. La conception du début à attendre une session donnée inclure plusieurs connexions distinctes. L'État de la session devrait éventuellement avoir une sorte de délai d'attente, donc si le client disparaît pour qu'il ne continue pas de consommer des ressources sur le serveur, mais pour être honnête, il peut simplement être un cas d'enregistrement de l'état sur le disque après quelque temps.
En résumé, je ne pense pas que le choix du transport compte et j'irais au moins avec TCP pour commencer. Ce qui compte vraiment est de pouvoir gérer l'état de la session de votre client sur le serveur et faire face au fait que les clients se connecteront et se déconnectent régulièrement.
Vous pouvez également être intéressé à consulter cette question: