Мне нужно отправить большие двоичные (2Gb-10Gb) данные с одного компьютера (клиента) на другой компьютер (сервер) через Интернет. Сначала я попытался использовать службу WCF, размещенную в IIS, используя привязку wsHttpBinding с безопасностью сообщений, но это заняло много времени (несколько дней), что мне не подходит. Теперь я думаю о написании клиентских и серверных приложений с использованием сокетов. Было бы быстрее?
Как лучше всего это сделать?
Спасибо
Старый добрый FTP для меня подошел бы в этом случае. С его помощью у вас будет возможность восстановить прерванную передачу без необходимости переделывать работу с самого начала. Вы должны учитывать возможность того, что такая массовая загрузка может быть прервана по некоторым причинам.
При отправке больших объемов данных вы ограничены пропускной способностью соединения. И вам следует позаботиться о сбоях в связи. Небольшие сбои могут иметь большое значение, если вам нужно повторно отправить много данных.
Вы можете использовать BITS для передачи данных в фоновом режиме и разделения данных на блоки. Так что он позаботится о многих вещах для вас.
Это зависит от IIS (на сервере) и имеет клиент (API) для передачи данных. Таким образом, вам не нужно читать или писать основы передачи данных.
Я не знаю, будет ли это быстрее, но, по крайней мере, намного надежнее, чем выполнение одного запроса HTTP или FTP. И вы можете запустить его очень быстро.
Если пропускная способность является проблемой и ее не нужно отправлять через Интернет, вы можете проверить соединения с высокой пропускной способностью / малой задержкой, например, отправив DVD курьером.
Вы можете использовать BITS из .Net, на CodeProject есть оболочка.
Что ж, пропускная способность - это ваша проблема, даже более низкое значение сокетов вам не поможет, поскольку накладные расходы WCF не сильно влияют на длинные двоичные ответы. Может быть, ваш вариант — использовать какой-нибудь алгоритм сжатия потоковой передачи без потерь? При условии, что ваши данные сжимаемы (выполните пробный запуск с помощью zip, если он сжимает файл на локальном диске, вы можете найти подходящий алгоритм потоковой передачи). Кстати, я бы предложил предоставить поддержку резюме :)
Обычно наиболее уместно использовать что-то, что уже было написано для этого типа вещей. например FTP, SCP, rsync и т. д.
FTP поддерживает возобновление, если загрузка прервалась, хотя не уверен, что он поддерживает возобновление загрузки. Rsync намного лучше справляется с такими вещами.
РЕДАКТИРОВАТЬ: Возможно, стоит подумать о чем-то, с чем я не очень знаком, но может быть другой вариант — бит-торрент?
Еще один вариант — создать свой собственный клиент/сервер с использованием библиотеки протоколов, такой как UDT, которая даст вам лучшую производительность, чем TCP. См.: http://udt.sourceforge.net/
Хотя существуют некоторые накладные расходы на полосу пропускания, связанные с платформами более высокого уровня, я обнаружил, что передача файлов WCF в виде потока выполняется более чем достаточно быстро. Обычно так же быстро, как обычная передача файлов по SMB. Я передал сотни тысяч небольших файлов за сеанс, в том числе большие файлы размером 6-10 ГБ, иногда больше. Ни разу не было серьезных проблем с каким-либо приличным соединением.
Мне очень нравятся интерфейсы, которые он предоставляет. Позволяет вам делать некоторые довольно интересные вещи, которые FTP не может, такие как удаленное взаимодействие или дуплексные конечные точки. Вы получаете программный контроль над каждым аспектом соединения с обеих сторон, и они могут передавать сообщения вместе с файлами. Веселые вещи.
Да, FTP быстрый и простой, если вам не нужны все эти вещи.
