Лучший способ перемещения файлов разных размеров по медленной сети с использованием .NET - PullRequest
5 голосов
/ 29 марта 2010

Я создаю клиент / сервер удаленного взаимодействия .NET, который будет передавать тысячи файлов различного размера (всего от нескольких байтов до сотен МБ), и я хотел бы получить некоторые отзывы о наилучшем способе достижения этот. На мой взгляд, есть несколько вариантов:

  • Сериализация всего файла в мой удаленный объект и передача сразу, независимо от размера. Это, вероятно, будет самым быстрым, но сбой во время передачи требует повторной передачи всего файла без возможности возобновления.
  • Если размер файла больше, чем что-то маленькое (например, 4 КБ), разбейте его на куски по 4 КБ и удалите их, собрав их на сервере. В дополнение к сложности этого, он медленнее из-за продолжающихся циклов и подтверждений, хотя отказ любого отдельного элемента не тратит много времени.
  • Включая что-то вроде сервера FTP или SFTP с моим приложением - клиент уведомит сервер о том, что он начинает использовать удаленное взаимодействие, загрузит файл, а затем использует удаленное взаимодействие, чтобы уведомить о завершении. Я хотел бы содержать все в своем приложении вместо того, чтобы требовать отдельную службу FTP, но я открыт для этой опции, если это необходимо.
  • Используйте какое-либо заявленное TCP-соединение или WPF или другой метод передачи, который создан для обработки сбоев или способен выполнять какую-то контрольную точку / возобновление.
  • Кто-нибудь еще мне не хватает?

Какой самый гибкий / надежный способ передачи? Меня не беспокоит скорость, а больше надежность - я хочу, чтобы файл двигался, даже если он медленно. Поскольку клиент и сервер будут многопоточными, я могу передавать несколько файлов одновременно, если это позволяет соединение.

Спасибо за ваш отзыв - я добавлю вознаграждение, чтобы получить некоторые рекомендации о том, как люди могут это сделать.

Ответы [ 3 ]

4 голосов
/ 01 апреля 2010

БИТОВ (фоновая интеллектуальная служба передачи) является хорошим решением. Он имеет многолетний опыт работы в

Некоторые отправные точки

1 голос
/ 31 марта 2010

Хотя спокойствие действительно отвечает на вопрос, который вы задаете со стороны жизни уровня 4 OSI, я чувствую, что вы больше смотрите на уровни приложений в своем вопросе. TCP определенно обрабатывает все, начиная от задержки, окон передачи и т. Д. На стороне сети. Однако он не определяет напрямую, что произойдет, если пользователь преждевременно завершит сеанс загрузки, а затем решит забрать его позже, когда он остановился.

Чтобы ответить на ваш вопрос под другим углом, я бы определенно рекомендовал разбить файл на секции и проиндексировать их для всех соединений, независимо от скорости. Затем они могут быть повторно собраны на клиенте после загрузки всего файла. Это позволяет пользователю приостанавливать сеансы загрузки и возобновлять работу.

Что касается определения скорости, для этого могут быть предварительно созданы методы, но один из методов, который вы можете использовать, - это просто создать свой собственный тест скорости: Отправьте 1 МБ клиенту (загрузите), и он отправит ответ после получения. 1100, разделенное на время, необходимое для получения ответа от клиента, - это КБ / с, которые клиент загружает с сервера. И наоборот, чтобы проверить загрузку с клиента.

Что касается передачи, я бы рекомендовал использовать существующие технологии. SFTP поддерживает аутентифицированную передачу зашифрованных данных. Это в основном FTP, но по SSH. Где-то должны быть доступны API-интерфейсы для взаимодействия с этим.

Кстати, я никогда не делал ничего такого, о чем вы говорите, но, надеюсь, мои идеи, по крайней мере, дадут вам пару вариантов для рассмотрения.

0 голосов
/ 29 марта 2010

Это то, для чего сам TCP создан и настроен в течение десятилетий или тяжелых испытаний. Удаленное управление сделано для небольших вызовов RPC, а не для передачи больших файлов. Вы должны просто использовать TCP-сокет для передачи данных и позволить протоколам нижнего уровня беспокоиться о задержке, окнах передачи, MTU и т. Д.

...