Здравствуйте.

У меня есть вопрос познавательного характера о именованных каналах.

У меня есть сервер, где транспорт реализован посредством именованных каналов.

Клиент к серверу подключается по сети, а не локально.

На стороне сервера с помощью функции ReadFile я асинхронно читаю из именованного канала.

В моем случае функция ReadFile сразу "сваливается" в фоновую работу, т.е. сразу происходит из нее выход и GetLastError возвращает ERROR_IO_PENDING. После этого я жду с помощью функции WaitForMultipleObjects завершения операции. После чего с помощью функции GetOverlappedResult узнаю сколько реально было прочитано.

Размер буферов именованного канала в моем случае 32кб. Также я провожу чтение блоками по 32 кб.

При анализе логов я заметил, что значение BytesTransfered, возвращаемое функцией GetOverlappedResult, имеет всего 2 значения: 4292 или 1155, причем первое число встречается значительно чаще.

ВОПРОС.
Есть ли какие-то "магические" числа, сходные с указанными выше? Ну там, размеры пакетов IP или еще что?

Просто интересно.

Спасибо :)

А, еще забыл сказать, что каналы имеют тип PIPE_TYPE_BYTE. Т.е. это потоки байтов, а не сообщения. Протокол я определяю сам - вначала 4 байта длины, потом сами данные.

> ВОПРОС.
> Есть ли


ОТВЕТ:
Нет.
И быть не может.

Не, ну должно быть что-то закономерное в этом. У меня нагрузочное тестирование было в течении нескольких часов - результат именно такой-же.
Видимо как-то с размером пакета IP связано. Или вообще что-то с канального уровня поднимается такое. Ибо локально такой закономерности нет.

Ладно, спасибо и  на этом. Видимо, если и есть здесь закономерность, то ее знают только производители оборудования.

> Видимо как-то с размером пакета IP связано


Какой нафих IP ?

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

> Какой нафих IP ?
>
> Стек протоколов, базирующихся на IP, может быть вообще не
> инсталлирован в твоей системе, однако именованые пайпы обязаны
> работать ..


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

Собственно вопрос имеет и практический смысл. Может я что-то неверно написал в своем сервере, что идет чтение такими, в общем-то, небольшими кусками по 4кб. Я обнаружил по логу, что почти 100% операций ReadFile никогда не выполняются синхронно, а сразу сваливаются в оверлаппед режим, хотя, судя по MSDN, синхронное выполнение чтения даже при задании последним параметром структуры OVERLAPPED все равно возможно (как минимум при запуске сервера и клиента на одной машине *большинство* операций чтения заканчиваются синхронно).

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

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

Если есть у кого опыт написание серверов на именованных каналах, поделитесь, пожалуйста, опытом.

Спасибо.

Оп-ля. А кто перекинул сей топик из WinAPI в "Прочее"?
И почему?