Здравствуйте, Александр Пристенский, Вы писали:

АП>Статья:
АП>Пример реализации inetd для Windows

Автор(ы): Александр Пристенский
Дата: 12.07.2005
Пример реализации inetd для windows представляет собой многопоточный сервер, запускающий дочерние процессы (консольные приложения) ввод-вывод которых перенаправляется на сокет.

АП>Авторы:
АП> Александр Пристенский

АП>Аннотация:
АП>Пример реализации inetd для windows представляет собой многопоточный сервер, запускающий дочерние процессы (консольные приложения) ввод-вывод которых перенаправляется на сокет.

Несколько замечаний:

— Довольно странная реализация keep-alive, которая почему-то делается вмешательством в application protocol. Время от времени сервер отправляет 1 байт. Этот байт дойдет до клиента. Что, спрашивается, клиент должен с ним делать? А ведь keep-alive поддерживается на транспортном уровне (SO_KEEPALIVE).

Кстати:

Несколько слов о keep-alive сообщениях. Допустим у клиента возникли проблемы с соединением — сбой сети, неожиданное закрытие клиентского приложения из-за ошибки и т.д. Цикл чтения-записи будет при этом продолжаться бесконечно – функция select() будет завершаться, и констатировать просто отсутствие данных от клиента

Это не так. select покажет, что сокет можно читать, а recv скажет, что прочел 0 байтов. Выполнение этих двух условий однозначно определяет, что партнер закрыл свою сторону, и данных от него больше никогда не будет.

— Определение состояния канала по состоянию дочернего процесса. Сомнительная техника. Например, дочерний процесс породил внучку, передал ей каналы, и завершился. Беда.

— Что там такое с телнетом, я совсем не понял. Не кажется ли, что сервер много на себя берет?

Послушайте! Ведь если байты посылают,
Значит это кому-нибудь нужно,
Значит, кто-то хочет, чтоб они были...

... а сервер их раз, и фильтрует.

— send тоже имеет право заблокироваться, и writability тоже надо проверять селектом.

Пока, вроде бы, все.