5 votes

Meilleur moyen de déplacer des fichiers de tailles variables à travers un réseau lent en utilisant .NET

Je construis un client/serveur .NET remoting qui va transmettre des milliers de fichiers, de tailles variées (allant de quelques octets à des centaines de Mo), et j'aimerais des retours sur la meilleure méthode pour y parvenir. Tel que je le vois, il y a quelques options:

  • Sérialiser l'intégralité du fichier dans mon objet de remoting et le transmettre d'un coup, peu importe sa taille. Cela serait probablement le plus rapide, mais en cas d'échec pendant la transmission, il faudrait recommencer tout le fichier, sans possibilité de reprise.
  • Si la taille du fichier est plus grande qu'un seuil (comme 4 Ko), le diviser en morceaux de 4 Ko et les envoyer à distance, puis les réassembler côté serveur. En plus de la complexité de cette méthode, c'est plus lent en raison des aller-retours et des accusés de réception, bien qu'un échec d'un morceau n'oblige pas à recommencer tout le processus.
  • Inclure quelque chose comme un serveur FTP ou SFTP avec mon application - le client informera le serveur de son début d'utilisation du remoting, téléchargera le fichier, puis utilisera le remoting pour signaler la fin. J'aimerais tout contenir dans mon application au lieu d'avoir besoin d'un service FTP séparé, mais je suis ouvert à cette option si c'est nécessaire.
  • Utiliser un type de connexion TCP à état ou WPF ou tout autre méthode de transmission capable de gérer les échecs ou de faire une sorte de checkpoint/reprise.
  • D'autres que j'aurais omis?

Quelle est la méthode de transmission la plus flexible/fiable? Je ne me soucie pas vraiment de la vitesse, mais plus de la fiabilité - je veux que le fichier soit déplacé, même si c'est lentement. Comme le client et le serveur seront multi-threadés, je peux transmettre plusieurs fichiers en même temps si la connexion le permet.

Merci pour vos retours - je vais offrir une prime pour obtenir des recommandations sur les façons dont les gens réaliseraient cela.

4voto

TFD Points 10618

BITS (background Intelligent Transfer Service) est une bonne solution. Il a des années d'expérience intégrées

Certains points de départ sont

1voto

regex Points 2247

Bien que calmh réponde à la question que vous posez du côté de la couche OSI 4, j'ai l'impression que vous regardez davantage les niveaux d'application dans votre question. TCP gère certainement tout, de la latence aux fenêtres de transmission, etc. du côté du réseau. Cependant, il ne détermine pas directement ce qui se passe si un utilisateur met fin prématurément à une session de téléchargement et décide ensuite de la reprendre là où il s'était arrêté.

Pour répondre à votre question d'un autre angle, je recommanderais certainement de découper le fichier en sections et de les indexer pour toutes les connexions, quelle que soit la vitesse. Elles peuvent ensuite être réassemblées sur le client une fois que le fichier complet est téléchargé. Cela permet à l'utilisateur de mettre en pause les sessions de téléchargement et de reprendre.

En ce qui concerne la détermination de la vitesse, il peut exister des méthodes préconstruites pour le faire, mais une méthode que vous pourriez utiliser consiste simplement à créer votre propre test de vitesse : Envoyez 1 Mo au client (téléversement) et demandez-lui de répondre une fois reçu. Divisez 1100 par le temps mis pour recevoir la réponse du client, cela vous donnera le débit en Ko/s qu'il faut au client pour télécharger depuis le serveur. Et vice versa pour tester le téléversement depuis le client.

En ce qui concerne la transmission, je vous recommanderais d'utiliser des technologies existantes. SFTP prend en charge le transfert de données cryptées authentifiées. C'est essentiellement du FTP, mais via SSH. Il devrait y avoir des APIs disponibles quelque part pour interagir avec cela.

En passant, je n'ai jamais rien fait à l'ampleur dont vous parlez, mais j'espère que mes idées vous donneront au moins quelques options à considérer.

0voto

Jakob Borg Points 10869

C'est pour cela que TCP a été conçu, et optimisé pendant des décennies de tests rigoureux. Le "remoting" est destiné aux petits appels de procédure à distance (RPC), pas aux transferts de gros fichiers. Vous devriez simplement utiliser un socket TCP pour transmettre les données, et laisser les protocoles de couche inférieure se soucier de la latence, des fenêtres de transmission, de l'unité maximale de transmission (MTU), etc.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X