АП>Пример реализации inetd для windows представляет собой многопоточный сервер, запускающий дочерние процессы (консольные приложения) ввод-вывод которых перенаправляется на сокет.
Статья неплохая, но несколько замечаний.
1.
Поскольку _beginthreadex() требует полный путь к исполняемому файлу
Наверное, имелось в виду CreateProcess? Но и в этом случае, выделенная фраза неверна — при задании пути в параметре lpCommandLine поведение при поиске аналогично стандартному в cmd.
2. Поскольку в Win NT вполне можно передавать в качестве стандартных хендлов сокеты, то очевидно, необходимости создавать промежуточные пайпы (и лишние треды) там нет. Достаточно правильно создать сокет. Например, как
здесьАвтор: Andrew S
Дата: 19.07.05
Здравствуйте, Александр Пристенский, Вы писали:
АП>Пример реализации inetd для windows представляет собой многопоточный сервер, запускающий дочерние процессы (консольные приложения) ввод-вывод которых перенаправляется на сокет.
Маленькое замечание по коду:
printf("\nWSAStartup() failed with error: %i", WSAGetLastError());
В случае неудачи
WSAStartup() код ошибки нельзя получить функцией WSAGetLastError(). WSAStartup() сама должна вернуть его.
Здравствуйте, Александр Пристенский, Вы писали:
АП>Статья:
АП>Пример реализации 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 тоже надо проверять селектом.
Пока, вроде бы, все.
Здравствуйте, vnp, Вы писали:
vnp>- Что там такое с телнетом, я совсем не понял.
в выводе команды dir например есть байты FF, когда этот вывод отсылается телнету он воспринимает то что после FF как команды себе родному и честно пытается эту случайную муть выполнять, хотя dir ничего такого ввиду не имел
vnp>Не кажется ли, что сервер много на себя берет?
дык ведь только если попросишь через опцию –FF
vnp>vnp>Послушайте! Ведь если байты посылают,
vnp>Значит это кому-нибудь нужно,
vnp>Значит, кто-то хочет, чтоб они были...
vnp>... а сервер их раз, и фильтрует.
а какие еще варианты?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
