Какой самый быстрый способ отправить большой двоичный файл с одного компьютера на другой через Интернет?

Question

Мне нужно отправить большие двоичные данные (2 ГБ-10 ГБ) с одного компьютера (клиента) на другой компьютер (сервер) через Интернет. Сначала я попытался использовать службу WCF, размещенную в IIS, используя привязку wsHttpBinding с безопасностью сообщений, но это заняло много времени (несколько дней), что для меня неуместно. Теперь я думаю о написании клиентских и серверных приложений с использованием сокетов. Будет ли это быстрее?

Каков наилучший способ сделать это?

Спасибо

Answer 1

Обычный старый FTP для меня подойдет в этом случае.С его помощью вы сможете восстановить прерванную передачу без необходимости повторного выполнения задания с самого начала.Вам необходимо учитывать возможность прерывания столь массовой загрузки по некоторым причинам.

Answer 2

При отправке больших объемов данных вы ограничены пропускной способностью соединения.И вам следует позаботиться о перебоях в связи.Небольшие сбои могут оказать большое влияние, если вам придется повторно отправить много данных.

Вы можете использовать БИТЫ , это переносит данные в фоновом режиме и разделяет данные на блоки.Так что позаботится о многих вещах для вас.

Это зависит от IIS (на сервере) и имеет клиента (API) для передачи данных.Таким образом, вам не нужно читать или записывать основы данных, передающих данные.

Я не знаю, будет ли это быстрее, но, по крайней мере, намного надежнее, чем выполнение одного запроса HTTP или FTP,И он может работать очень быстро.

Если пропускная способность является проблемой, и ее не нужно отправлять через Интернет, вы можете проверить соединения с высокой пропускной способностью / низкой задержкой, такие как отправка DVDкурьером.

Вы можете использовать БИТЫ из .Net, на CodeProject есть обертка .

Answer 3

Обычно наиболее целесообразно использовать что-то, что уже было написано для такого типа вещей.например, FTP, SCP, rsync и т. д.

FTP поддерживает возобновление, если загрузка прервалась, хотя не уверен, поддерживает ли она возобновленную загрузку.Rsync гораздо лучше справляется с подобными вещами.

РЕДАКТИРОВАТЬ: Возможно, стоит рассмотреть что-то, с чем я не очень знаком, но может быть другой вариант - бит-торрент?

А дальшевариант состоит в том, чтобы прокрутить свой собственный клиент / сервер с использованием библиотеки протоколов, такой как UDT, которая даст вам лучшую производительность, чем TCP.Смотри: http://udt.sourceforge.net/

Answer 4

Ну, пропускная способность - это ваша проблема, даже если вы сократите ее в сокеты, это вам мало поможет, так как накладные расходы WCF мало влияют на длинные двоичные ответы.Может быть, ваш вариант - использовать какой-нибудь алгоритм сжатия без потерь?При условии, что ваши данные сжимаемы (выполните пробный прогон, используя zip, если он сжимает файл на локальном диске, вы можете найти подходящий алгоритм потоковой передачи).Кстати, я бы предложил обеспечить поддержку резюме:)

Answer 5

Хотя с инфраструктурами более высокого уровня связаны некоторые накладные расходы на пропускную способность, я обнаружил, что передача файлов WCF в виде потока выполняется более чем достаточно быстро. Обычно так быстро, как обычная передача файлов через SMB. За один сеанс я передал сотни тысяч маленьких файлов, которые включали большие файлы размером 6-10 ГБ, иногда больше. Никогда еще не было никаких серьезных проблем из-за какой-либо достойной связи.

Мне действительно нравятся интерфейсы, которые он предоставляет. Позволяет вам делать довольно интересные вещи, которые FTP не может использовать, например удаленное взаимодействие или дуплексные конечные точки. Вы получаете программный контроль над каждым аспектом соединения с обеих сторон, и они могут передавать сообщения вместе с файлами. Прикольные вещи.

Да, FTP быстрый и простой, если вам не нужны все эти вещи.