Path MTU Discovery

Question

Я разрабатываю приложение, которое обрабатывает (обработка видео и т. Д.) И отправляет большие файлы (до десятков гигабайт) по сети. Я отправляю файлы по FTP. Чтобы улучшить производительность / потребление памяти приложением, я хотел бы оптимизировать буферы, чтобы я не отправлял слишком большие и фрагментированные пакеты. У меня проблема в том, что у меня не так много оперативной памяти для хранения данных файла во время отправки. По сути, я читаю с диска достаточно байтов, обрабатываю его и сразу отправляю к месту назначения. В настоящее время я ищу для реализации обнаружения пути MTU.

Я знаком с основной концепцией того, как это сделать. Я хотел бы знать, есть ли какой-либо .NET API в Windows, который отслеживает MTU до места назначения?

Я предполагаю, что такого нет, но мой друг сказал мне, что Windows Vista отслеживает.

Я занимаюсь разработкой этого приложения для Windows XP, но я хотел бы узнать, есть ли такой интерфейс отслеживания сети в Windows.

Answer 1

winsock не поддерживает сообщение об обнаруженном MTU, хотя другие стеки TCP / IP поддерживают (например, AIX через опцию сокета IP_GETPMTU). Поскольку winsock не может сообщить об этом, .NET не может предоставить API (который должен быть поверх winsock).

Рекомендую отправлять данные кусками по 64киБ. Это максимальный размер IP-пакета и, вероятно, больше, чем MTU, поэтому стек будет отправлять несколько полных сегментов. Последний фрагмент может быть меньше, но тогда система может отложить его отправку (поскольку ей все еще нужно получать подтверждения для более ранних данных), поэтому, если вы быстро выполните следующую отправку 64 КБ, система снова объединит фрагменты пакеты с использованием пути mtu.

Answer 2

PMTU Discovery используется вашим стеком TCP исключительно для оптимизации размера пакета при отправке. На вашем уровне вы видите только поток (т. Е. Еще до того, как произойдет пакетирование, не говоря уже о фрагментации). На самом деле ваша проблема звучит так: вы пытаетесь отправить данные как можете, однако ваше соединение tcp / ip медленнее, так что это приводит к увеличению пространства, необходимого в оперативной памяти. Поскольку вы используете FTP, я ожидаю, что используемая вами реализация FTP уже будет поддерживать и понимать это ??? Поскольку вы запрашиваете буферы, это звучит как ваш собственный бросок на основе сокета или что-то в этом роде. Если вы используете методы синхронной отправки, когда буфер сокета заполнен, он должен блокировать отправку, пока он не освободит место в буфере.

Можете ли вы дать более подробную информацию о том, какой API вы используете для отправки файла, Встроенный или Roll ваш? Будь то сокет, сетевой поток и т. Д.

Answer 3

Используйте FtpWebRequest и FtpWebResponse. Дело в том, что эти классы используют не огромные буферы, а потоки (которые реализованы с использованием буфера наилучшего размера). Использование памяти будет очень минимальным.

Размер пакета находится не под вашим контролем, а под сетевым драйвером.

Если вам нужна лучшая скорость, то реализуйте отправку / получение данных через класс TcpClient на стороне сервера и клиента.

UPD: Вот пример того, как файлы должны быть загружены: http://msdn.microsoft.com/en-us/library/system.net.ftpwebrequest.aspx См. class AsynchronousFtpUpLoader.

Еще одна вещь. Некоторое время назад я экспериментировал с MTU. Все мои изменения снизили скорость передачи данных. Сетевой драйвер Windows достаточно умен, чтобы использовать лучший MTU.

Answer 4

Если вы используете UDP, вас может беспокоить фрагментация, но если это так, почему вы используете собственный протокол для передачи больших файлов? Вместо этого используйте TCP и не беспокойтесь об этом. Если вы реализуете свой собственный протокол по UDP с управлением перегрузкой и всем остальным, что вам нужно, установите бит DF для пакетов и обработайте ответы.

Если вы используете TCP, вам не нужно беспокоиться о фрагментации, стек сделает это за вас.

Answer 5

Это не то, что вы должны делать сами, при условии, что вы используете TCP. Кроме того, нет никакого отношения к размеру ваших буферов отправки. Может быть несколько пакетов в пути (до размера окна TCP), но они больше не будут находиться в поддерживаемом вами буфере.