Re: WSAxxx vs. unix-live IO (Re: fprintf && write)

From: Igor Sysoev ()
To: Boris Rudakov ()
Date: 2003-06-10T17:23:16Z
Area: CARBON.COPY
 * Forwarded from area 'RU.UNIX.PROG'
From: Igor Sysoev <is@rambler-co.ru>

Boris Rudakov <Boris.Rudakov@p4.f9.n5054.z2.fidonet.org> wrote:

> IS> А вот в cамом конце восьмой главы первого издания "Network
> IS> programming for Microsoft Windows"

>Эт' чего за книга ?
>Какой год, кто автор ? Microsoft Press ? В MSDN входит ?

ISBN 0-7356-0560-2, 1999 год, авторы Anthony Jones и Jim Ohlund.
Есть русский перевод. Уже вышло второе издание:
http://www.microsoft.com/mspress/books/sampchap/5726.asp
Есть ли оно на MSDN - я не знаю, но у меня есть CHM, вероятно, оттуда.

>Выыод: сокеты поддерживаются не поверх других средств Win32, в "параллельно
>им", опираясь на ядро. Я ошибался, считая что winsock - вторичное API. Итак,
>сокеты и другие средства работы с файлами - разные "фланги" фронта Win32,
>ретранслирующего вызова в ядро НТи, представленное NTDLL. Значит НЕКОТОРАЯ
>оптимизация в WSAxxx - ВОЗМОЖНА.

Я полагаю, что Winsock недоступен через ntdll, вместо этого ws2_32 берёт
из реестра имена dll'ек, с которыми он будет работать, см. схему:
http://msdn.microsoft.com/msdnmag/issues/1000/Winsock/default.aspx

>1. Прокачка данных идет порциями по мере их подготовки. Реееееедко-редко
>возникает ситуация, когда сервер должен свалить в сокет многомегабайтный файл:
>смаппить его и за одну операцию записи целиком уронить в одну из возможных
>функций записи в сокет. Какой-то небольшой выигрыш за счет internal
>optimization тут может быть. А в большинстве же случаев сбрасываются по мере
>готовности маленькие порции данных и оптимизация самого вывода - не самое
>главное.

>3. Сложному приложению нельзя просто взять, инициировать операцию прокачки
>данных и уснуть пока она не завершится. а) у "тяжелого сервера" этих операций
>одновременно может быть несколько тысяч (если не десятков тысяч), б) пока
>что-то качается еще есть масса другой работы, которую надо делать, а не спать в
>блокирующем вызове, в) надо своевременно реагировать на различные управляющие
>события, типа команды "кансел это соединение нах".

Читая пункты 1 и 3, у меня создаётся впечатление, что ты считаешь,
что send и WSASend отличаются только именами и парой параметров. Это не так.
WSASend по функциональности превосходит WriteFile (разумеется, я говорю
только о сокетах). И, в частности, он так же, как и WriteFile, поддерживает
overlapped операции с уведомлением о завершении через event, completion
routine или i/o completion port.

>2. ReadFile/WriteFile - фундаментальные функции API, работающие над всеми
>объектами ядра, которые умеют писаться/читаться. Если ты делаешь модуль
>серверного приложения, реализующий универсальный конвейер ввода/вывода "всего",
>т.е. на общих основаниях прокачивающий данные по всем открытым каналам: пайпам,
>сокетам, портам - самое разумное написать универсальный код на основе
>фундаментальных функций и решить задачу "в общем виде", а не писать очень
>похожие кусочки для чуточку разных случаев.

Я согласен, что такой метод неплох. Однако сокеты имеют свои особенности,
а в виндах прибавляются ещё и свои. Например, в
http://www.microsoft.com/mspress/books/sampchap/5726a.asp?#130
описан метод работы с большим количеством вялотекущих соединений.
Там предлагается делать overlapped WSARecv с буфером нулевого(!)
размера только для того, чтобы получить уведомление о пришедших данных.
Сами же данные предлагается затем читать неблокирующимся WSARecv до получения
WSAEWOULDBLOCK. Вот тебе и generic решения.

>4. Есть такая препоганая штука как Мастдай, где весь API реализован и работает
>через жопу, и чем большее разнообразие средств API тобой применяется, тем
>сложнее следить за переносимостью софтины из родной системы (НТи) в это
>угробищще.

В 9X как раз-таки WSARecv есть, а вот ReadFile с сокетами работать не умеет.

>5. *Есть такая штука - юниксы* :):):):) куда код, основанный на
>"фундаментальных" средствах API, портируется относительно просто, а вот
>"оригинальное API", в данном случае WSAxxx - прибавляет лишнего головняка.

Для портирования в юникс единственный удобный интерфейс - это
select/send/recv. Overlapped ReadFile/WriteFile и WSARecv/WSASend в плане
портируемости ничем не отличаются.

>Я заблуждался.

Я думаю, этот процесс ещё не завершён.

>НО: портировать в юникс функцию на цикле ReadFile...GetOverlappedResult куда
>как проще, переделав ее в функцию на цикле read...select, чем мудохаться с ни
>на что не похожими WSA.

Как я уже сказал, WSARecv..GetOverlappedResult ничем не отличается
от ReadFile...GetOverlappedResult.


-- 
Игорь Сысоев
http://sysoev.ru
--- ifmail v.2.15dev5
 * Origin: Rambler Office news site (2:5020/400)