Низкая пропускная способность в именованных каналах Windows по глобальной сети

Question

У меня проблемы с низкой производительностью при использовании именованного канала Windows. Пропускная способность быстро падает с увеличением задержки в сети. Существует примерно линейная зависимость между сообщениями, отправляемыми в секунду, и временем прохождения туда и обратно. Кажется, что клиент должен подтвердить каждое сообщение, прежде чем сервер отправит следующее. Это приводит к очень низкой производительности, я могу отправлять только 5 (~ 100 байт) сообщений в секунду по каналу с RTT 200 мс.

Канал асинхронный, использует несколько операций записи с перекрытием (и несколько операций чтения с перекрытием на стороне клиента), но это не улучшает пропускную способность. Можно ли отправлять сообщения параллельно по именованному каналу? Канал создается с использованием PIPE_TYPE_MESSAGE, будет ли PIPE_READMODE_BYTE работать лучше? Есть ли другой способ улучшить производительность?

Это развернутое решение, поэтому я не могу просто заменить канал подключением через сокет (я читал, что именованный канал Windows не рекомендуется использовать по глобальной сети, и мне интересно, почему ). Буду благодарен за любую помощь в этом вопросе.

Answer 1

Мы обнаружили, что у Named Pipes низкая производительность по сравнению с Windows XP и выше.

У меня нет решения для вас. Но я согласен с тем, что Named Pipes бесполезны начиная с XP. Из-за этого мы полностью изменили наше программное обеспечение (с точки зрения IPC).

Ваши коммюнике разложены в отдельную DLL? Возможно, вы могли бы заменить DLL на интерфейс, который выглядит так же, но ведет себя по-другому?

Answer 2

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

Answer 3

Я реализовал обходной путь, введя небольшую (~ 1 мс) фиксированную задержку, чтобы буферизовать как можно больше данных перед записью в канал. По сетевому каналу с RTT 200 мс я могу отправлять в десять раз больше данных примерно за треть времени.

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