>[оверквотинг удален]
>>делается)
>
>Пардонте, но прибить гвоздями размер tcp window не возможно.
>
>>но реальных ситуаций когда должны передаваться огромные данные
>>а начинают передаваться по байту
>>я никогда не сталкивался
>
>Эм... вы никогда не видели как медлено и печально DDOSят веб сервера?
>с ДДосом боряться на уровне системы а не в реализациях клиент <->серверных приложениях
даже при ~100 коротких ДДОс
мне не накладно (если алгоритм программы оптимизированый) пробежаться read, close, по некорректных запросах
далее это уже дело системы и администратора
>[оверквотинг удален]
>> а здесь уже
>>звать эту процедуру
>> ->udata();
>> которая и сделает
>>accept и остальное что надо, к примеру уже добавит
>> дополнительные EV(ADD, some_recv,....
>
>Да какая разница, зовете вы сискол напрямую или через обертку. Это детали
>реализации.
>Да и сложностей я тут не вижу. Вы все равно должны проверять eventlist[i]->filter хотябы 1 раз [а вдруг там EV_ERROR получился], либо иметь лишний вызов kevent для установки changelist на каждый добавляемый эвент.
лишнего вызова kevent нет, EV_ERROR проверяеться
>
>>а я это запустил еще в функции some_accept, смотрите выше
>
>Простите, но почему-то не верю) Вы выше писали, что не используете поле
>data, а крутить accept пока не получим EWOULDBLOCK как-то не комильфо.
>
я не использую ->data
я использую ->udata
>
>>потому что мне нет смысла получать дополнительный евент с data что бы
>>знать количество ожидающих listen
>
>Ну где, где вы там углядели доп. event????
>Там ровно один event на каждый сокет который мы слушаем, возвращающий нужное
>число. Да и у вас тоже оно возвращается хотите вы этого
ок. вы меня пытаетесь убедить что в ->data возращаеться количество ожидающих listen ?
что бы потом по этим while ( ->data --) accept пробежаться?
>или нет, вот только вы его упорно игнорируете)
>К тому же цена 1 или 10 эвентов для kqueue стремиться к
>0 по сравнению с одним лишним сисколом.
