Передача файлов UDP - Да, UDP

Question

У меня есть требование для создания системы передачи файлов UDP.Я знаю, что TCP гарантирован и гораздо более надежен, но мне нужно передавать огромные файлы между локациями, и я думаю, что преимущество в скорости в этом проекте перевешивает преимущества использования TCP.Я только начинаю этот проект, но хотел бы получить руководство, если кто-то делал это раньше.Я буду писать обе стороны (клиент и сервер), поэтому мне не нужно беспокоиться об ограничениях возможностей других продуктов.

В двух словах:

• Возьмите большоефайлы и отправлять их кусками
• Уметь регулировать пропускную способность от клиента
• Создать какую-то систему нумерации пакетов для ошибок, повторных передач и сборки файлов по чанкам на сервере (да, все вещимы получаем из TCP бесплатно: -)
• Конфигурируемый размер датаграмм - я думаю, что некоторые брандмауэры жалуются, если они становятся слишком большими?* Я начинаю это путешествие с помощью UdpClient и хотел бы написать это приложение на C #.Любые слова мудрости (кроме использования TCP)?

  ---

  Это было сделано с огромным успехом.Мы использовали RocketStream.com, но они продавали свой продукт другой компании только для внутреннего пользования.Обычно мы получаем скорости, в 30 раз превышающие скорость передачи FTP или байтов TCP.

Answer 1

в отношении

Настраиваемый размер датаграммы - я думаю, что некоторые брандмауэры жалуются, если они становятся слишком большими?

одна датаграмма может составлять до 65 536 байт. С учетом всей информации заголовка ip вы получите 65 507 байт для полезной нагрузки. но вы должны рассмотреть, как все устройства настроены по вашему сетевому пути. Как правило, для большинства устройств установлен размер MTU 1500 байт, так что обычно это будет ваш лимит «в Интернете». если вы настроите выделенную сеть между вашими местоположениями, вы можете увеличить MTU для всех устройств.

дальше в отношении

Создать какую-то систему нумерации пакетов для ошибок, повторных передач и сборки файлов по частям на сервере (да, все, что мы получаем из TCP бесплатно: -)

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

32-байтовый порядковый номер 8-байтовая контрольная сумма crc32 (поправьте меня по байту) любые оставшиеся байты могут быть использованы для данных

надеюсь, что это даст вам некоторое направление

:: редактировать ::

По опыту могу сказать, что UDP на 10-15% быстрее, чем TCP в выделенных и настроенных UDP сетях.

Answer 2

У меня только что была идея ...

1. разбить файл на 16k кусков (длина произвольна)
2. создать HASH для каждого чанка
3. передатьвсе хэши чанков, используя любой протокол
4. на приемном конце, подготовьте хэшированием всего, что у вас есть на жестком диске, в сети, я имею в виду все, в 16k чанках
5. сравните полученные хеши с вашимлокальные хеши и восстановите данные, которые у вас есть
6. загрузите остальные, используя любой протокол

Я знаю, что я на 6 месяцев отстал от графика, но я просто не смог устоять.

Answer 3

Это было бы круто, если бы вы добились успеха.

Не делай этого без WireShark. Вам это понадобится.

Для алгоритма, я думаю, у вас есть идея, как начать. Может быть, некоторые указатели:

1. начните с MTU, который будет общим для обеих конечных точек, и используйте пакеты только такого размера, так что вы будете иметь контроль над фрагментацией пакетов (когда вы выйдете из TCP, я надеюсь, что это для большего контроля над низким уровень вещи).
2. вам, вероятно, захочется заглянуть в STUN или TURN, чтобы пробить дыры в NAT.
3. Загляните в ZModem - это также имеет ностальгическое значение:)
4. , так как вы хотите выжать максимум из вашей ссылки, постарайтесь поместить как можно больше в «контрольные пакеты», чтобы не тратить ни одного байта.
5. Я бы не использовал CRC на уровне пакетов, потому что, полагаю, сети под ним обрабатывают все это.

Answer 4

Я не уверен, что увеличение скорости будет огромным, но интересный эксперимент.Такой протокол будет выглядеть и вести себя больше как один из традиционных протоколов, основанных на модемах, и, вероятно, ZModem является одним из лучших примеров, чтобы получить вдохновение (реализует окно подтверждения, адаптивный размер блока и т. Д.).

Уже есть некоторые люди, которые пробовали это, проверьте этот сайт .

Answer 5

Другие говорили более интересные вещи, но я хотел бы отметить, что вам нужно убедиться, что вы используете хороший алгоритм сжатия.Это будет иметь огромное значение.

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

Наконец, подумайте, почему вы беретесь за эту задачу?Окупится ли выигрыш в скорости после того, как потрачено время на его разработку?