Aide TCP ou UDP avec un serveur/client en C#?

Question

Quelqu'un peut-il aider, j'essaie de comprendre ce que j'ai besoin de faire, on m'a donné les tâches d'écriture d'un serveur et un client en TCP (UDP). En gros, plusieurs clients vont se connecter au serveur .. et le serveur envoie MESSSAGES au client.

Je n'ai aucun problème à créer le serveur et le client mais avec tcp je ne suis pas sûr du chemin à parcourir. Est-ce que le .net 3.5 supporte tout ou dois-je partir à la recherche d'un composant? Je cherche de bons exemples avec C# pour TCP ou UDP. C'est là où je ne suis pas sûr à 100% .. pour autant que je sache, il y a UDP et TCP ... 1 est connecté et 1 n'est pas .. Alors de quelle façon puis-je aller et C# support à la fois ?? Avantages désavantages?

Dites si le serveur doit prendre en charge plusieurs clients dont j'ai seulement besoin d'ouvrir 1 port ou dois-je ouvrir 2?

De plus, si un client se bloque, je n'ai pas besoin d'effectuer le SERVEUR, donc le serveur peut l'ignorer et fermer la connexion si on est ouvert ou timeout une connexion ... Si en fait une connexion est nécessaire tcp udp

Des idées où je devrais commencer et choisir quel protocole et le nombre de ports que je vais devoir assigner?

grâce

Answer 1

Y a-t-il une exigence à faire à un niveau aussi bas? Pourquoi ne pas utiliser WCF? Il supporte entièrement la messagerie sur TCP/IP, en utilisant le transfert de données binaires, mais il est à un niveau beaucoup plus élevé d'abstraction que les sockets raw.

Answer 2

Tout ce dont vous avez besoin est en .Net 3.5 (et probablement ci-dessous). Consultez la documentation et les exemples avec la classe UdpClient sur MSDN pour obtenir des informations sur l'écriture de votre client/serveur. Un google rapide trouvé un exemple de code pour un server et client à www.java2s.com parmi beaucoup d'autres exemples de réseautage en C#. Ne soyez pas rebutés par le nom de domaine.

Answer 3

Il me semble que vous n'êtes pas clair sur la distinction entre TCP et UDP.

TCP est orienté connexion. c'est-à-dire que 2 pairs auront une connexion dédiée. La livraison et la commande des paquets sont garanties. Généralement, un serveur présente un port, et plusieurs clients peuvent se connecter à ce port (pensez à un serveur HTTP et à des navigateurs).

UDP est sans connexion. Il ne garantit pas la livraison des paquets, ni la commande. Vous pouvez implémenter des mécanismes de diffusion et de multidiffusion très facilement. Si vous avez besoin d'une certaine fiabilité, vous devrez l'implémenter en plus de UDP. Parfois, vous pouvez ne pas en tenir compte, et simplement émettre des demandes et réessayer sur aucune réponse (SNMP fait cela). Parce que c'est sans connexion, vous ne vous inquiétez pas vraiment des pairs qui montent/descendent. Vous avez juste à réessayer si nécessaire.

Votre choix de protocole est donc dicté par ce qui précède. par exemple. Votre client a-t-il besoin d'une connexion dédiée au serveur? Transmettez-vous les mêmes données à plusieurs clients? Pouvez-vous tolérer la perte de paquets (par exemple, mises à jour de prix en temps réel, etc.)? Peut-être est-il possible d'utiliser TCP et UDP pour différentes exigences au sein de votre application (par exemple TCP pour l'enregistrement des commandes, UDP pour la transmission des mises à jour/événements?)

Je considérerais vos exigences et vous familiariserais avec les limitations et les fonctionnalités de TCP et UDP. Cela devrait rendre les choses un peu plus claires.

Answer 4

contre UDP:

• restriction de taille de paquet signifie que vous ne pouvez envoyer des petits messages (moins d'environ 1,5k octets). Le manque de flux rend difficile la sécurisation du protocole UDP: difficile de faire un schéma d'authentification qui fonctionne sur un échange avec perte, et tout aussi difficile de protéger l'intégrité et la confidentialité des messages individuels (aucun état clé sur lequel s'appuyer).
• Aucune garantie de livraison signifie que votre cible doit être prête à gérer la perte de messages. Maintenant, il est facile de faire valoir que si la cible peut gérer une perte totale de messages (est possible) alors pourquoi prendre la peine de les envoyer en premier lieu?

UDP Les Plus:

• Pas besoin de stocker un point de terminaison du système sur le serveur pour chaque client (pas de prise.). C'est l'une des principales raisons pour lesquelles les jeux MMO connectés à des centaines de milliers de clients utilisent UDP.
• Vitesse: Le fait que chaque message soit acheminé individuellement signifie que vous ne pouvez pas atteindre une congestion de flux comme le peut TCP.
• Diffusion: UDP peut diffuser à tous les écouteurs sur un segment de réseau.

Vous ne devriez même pas envisager UDP si vous envisagez TCP également. Si vous envisagez TCP signifie que vous envisagez en termes d'un flux (exactement une fois dans les messages) et en utilisant UDP mettra le fardeau de la fragmentation, réessayer et accusé de réception, la détection des doublons et la commande dans votre application. Vous ne tarderez pas à réinventer TCP dans votre application et il a fallu à tous les ingénieurs dans le mot 20 ans pour obtenir que droite (ou au moins aussi vrai que c'est dans IPv4).

Si vous n'êtes pas familier avec ces sujets, je vous recommande d'aller avec le flux et d'utiliser WCF, au moins, il vous donne l'avantage de basculer et sortir avec une facilité relative divers transports et protocoles. Sera beaucoup plus difficile de changer votre base de code de TCP à UDP et vice versa si vous avez fait le mauvais choix en utilisant des composants socket .Net brutes.