Цитата из мана про EVFILT_READ:
Sockets which have previously been passed to listen() return when there is an incoming connection pending. data contains the size of the listen backlog.

Вопрос: backlog может быть больше чем указано в параметре listen()?

• kqueue/kevent,анонимус, 22:29 , 07-Июн-10
  • kqueue/kevent,guest, 23:01 , 07-Июн-10
    • kqueue/kevent,анонимус, 22:23 , 09-Июн-10
      • kqueue/kevent,guest, 10:22 , 10-Июн-10
        • kqueue/kevent,анонимус, 11:27 , 10-Июн-10
          • kqueue/kevent,guest, 20:44 , 10-Июн-10
            • kqueue/kevent,анонимус, 21:13 , 10-Июн-10
              • kqueue/kevent,guest, 21:39 , 10-Июн-10
                • kqueue/kevent,анонимус, 21:53 , 10-Июн-10
                  • kqueue/kevent,guest, 21:56 , 10-Июн-10
                    • kqueue/kevent,анонимус, 22:23 , 10-Июн-10
                      • kqueue/kevent,guest, 22:46 , 10-Июн-10
                        • kqueue/kevent,анонимус, 23:03 , 10-Июн-10
                          • kqueue/kevent,анонимус, 23:13 , 10-Июн-10
                          • kqueue/kevent,guest, 23:20 , 10-Июн-10
                            • kqueue/kevent,анонимус, 23:26 , 10-Июн-10
                              • kqueue/kevent,guest, 23:32 , 10-Июн-10
                                • kqueue/kevent,анонимус, 23:39 , 10-Июн-10
                                  • kqueue/kevent,guest, 23:47 , 10-Июн-10
                                    • kqueue/kevent,анонимус, 00:01 , 11-Июн-10
                                      • kqueue/kevent,guest, 00:35 , 11-Июн-10
                                        • kqueue/kevent,guest, 00:38 , 11-Июн-10
                                        • kqueue/kevent,анонимус1, 02:12 , 11-Июн-10
                                          • kqueue/kevent,guest, 09:53 , 11-Июн-10
                                            • kqueue/kevent,анонимус1, 12:11 , 11-Июн-10
                                              • kqueue/kevent,guest, 13:35 , 11-Июн-10

>Цитата из мана про EVFILT_READ:
>Sockets which have previously been passed to listen() return when there is
>an incoming connection pending. data contains the size of the listen
>backlog.
>
>Вопрос: backlog может быть больше чем указано в параметре listen()?

backlog и так выступает параметром в listen()
перефразируйте ваш вопрос, он не ясен

>backlog и так выступает параметром в listen()
>перефразируйте ваш вопрос, он не ясен

ок.
Вопрос: может ли значение возвращаемое kevent() в struct kevent.data для listen сокета быть больше чем бэклог заказанный в listen().

на всякий случай псевдокод:
listen(fd, BACKLOG);
EV_SET(&changelist, fd, EVFILT_READ, EV_ADD, 0, 0, 0);
kevent(kq, changelist, nchanges, eventlist, nevents, NULL);
if (evebtlist->data > BACKLOG)
        printf("да, так бывает")

>[оверквотинг удален]
>ок.
>Вопрос: может ли значение возвращаемое kevent() в struct kevent.data для listen сокета
>быть больше чем бэклог заказанный в listen().
>
>на всякий случай псевдокод:
>listen(fd, BACKLOG);
>EV_SET(&changelist, fd, EVFILT_READ, EV_ADD, 0, 0, 0);
>kevent(kq, changelist, nchanges, eventlist, nevents, NULL);
>if (evebtlist->data > BACKLOG)
>        printf("да, так бывает")

у вас неправильное представление о том как использовать kevent & socket
возьмите любой работающий код, к примеру inetd с freebsd и разберите его
возможно после этого у вас все прояснитсья

>у вас неправильное представление о том как использовать kevent & socket
>возьмите любой работающий код, к примеру inetd с freebsd и разберите его

Вы бы для приличия хоть одним глазом RTFS перед тем как советовать сделали, inetd select based во фре.

>возможно после этого у вас все прояснитсья

Проясняется потихоньку, отвечу сам себе:
FreeBSD: так не бывает.
OpenBSD: бывает. google kern.sominconn
NetBSD: так не бывает.

>>у вас неправильное представление о том как использовать kevent & socket
>>возьмите любой работающий код, к примеру inetd с freebsd и разберите его
>
>Вы бы для приличия хоть одним глазом RTFS перед тем как советовать
>сделали, inetd select based во фре.
>

ошибся, не во фре а в netbsd

>>возможно после этого у вас все прояснитсья
>
>Проясняется потихоньку, отвечу сам себе:
>FreeBSD: так не бывает.
>OpenBSD: бывает. google kern.sominconn
>NetBSD: так не бывает.

/usr/ports/net/bsdproxy/
http://people.freebsd.org/~jmg/kq.html

изучайте

повторю, вы не правильно используете kevent (судя по вашему псевдо коду)

>ошибся, не во фре а в netbsd

Спасибо, посмотрел. Там нет интересовавшего меня цикла с accept(), правда для inetd он наверное и не нужен.

>>ошибся, не во фре а в netbsd
>
>Спасибо, посмотрел. Там нет интересовавшего меня цикла с accept(), правда для inetd
>он наверное и не нужен.

зачем в accept циклы?

man kevent

res = kevent возращает количество данных с наступившими собитыями

что вы там в ->data > BACKLOG сравниваете я ума не приложу

> что вы там в ->data > BACKLOG сравниваете я ума не приложу

ман прочтите чтоли

>> что вы там в ->data > BACKLOG сравниваете я ума не приложу
>
>ман прочтите чтоли

поучите меня что ли
у меня клиент серверных приложений на kevent поболее будет

давайте выдержку из мана, в которой вы не можете разобраться

>давайте выдержку из мана, в которой вы не можете разобраться

EVFILT_READ    Takes a descriptor as the identifier, and returns whenever
                    there is data available to read.  The behavior of the
                    filter is slightly different depending on the descriptor
                    type.

                    Sockets
                        Sockets which have previously been passed to listen()
                        return when there is an incoming connection pending.
                        data contains the size of the listen backlog.

Помочь перевести или сами осилите?

ну теперь все совсем понятно
вы перевели неправильно
data не имелась ввиду ->data
а имелось ввиду результат выполнения функции
  res = kevent(..., &data[0], ....)
если res отличный от нуля и -1 значит в res количество событий для обработки, а в data[]
массив сработавший EVENT

это ясно и из любого примера использования kevent который вы так упорно не хотите найти и посмотреть
взять хотя бы всем известный nginx

>ну теперь все совсем понятно
>вы перевели неправильно
>data не имелась ввиду ->data
>а имелось ввиду результат выполнения функции
>  res = kevent(..., &data[0], ....)
>если res отличный от нуля и -1 значит в res количество событий
>для обработки, а в data[]
>массив сработавший EVENT

Слава Богу, что стандарты и маны пишете не вы, а адекватные люди.
Постарайтесь осознать, что когда в мане секций 2,3,9 говориться о каких либо переменных, структурах, функциях или массивах, то имеется ввиду именно то что написано.

>это ясно и из любого примера использования kevent который вы так упорно
>не хотите найти и посмотреть
>взять хотя бы всем известный nginx

Открою вам страшную тайну, nginx как раз использует эту фичу с kevent бэкэдом
почитайте ngx_event_accept и прочувствуйте что ev->available там как раз и есть struct kevent->data

>Слава Богу, что стандарты и маны пишете не вы, а адекватные люди.
>

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

>Постарайтесь осознать, что когда в мане секций 2,3,9 говориться о каких либо
>переменных, структурах, функциях или массивах, то имеется ввиду именно то что
>написано.

->data как и ->udata для пользователя, и пользователь их устанавливает или убирает

>
>>это ясно и из любого примера использования kevent который вы так упорно
>>не хотите найти и посмотреть
>>взять хотя бы всем известный nginx
>
>Открою вам страшную тайну, nginx как раз использует эту фичу с kevent
>бэкэдом
>почитайте ngx_event_accept и прочувствуйте что ev->available там как раз и есть struct kevent->data

#if (NGX_HAVE_LOWAT_EVENT)
        if (flags & NGX_LOWAT_EVENT) {
            kev->fflags = NOTE_LOWAT;
            kev->data = ev->available;

        } else {
            kev->fflags = 0;
            kev->data = 0;
        }
#else
        kev->fflags = 0;
        kev->data = 0;
#endif

показательно.. да... особенно NGX_HAVE_*
тогда желаю вам разобраться с ваши не пониманием самим, благо дело код BSD открыт вместе с реализацией kevent

обратитесь к автору nginx, поверте он хороший человек
надеюсь он вас вразумит

>сьязвили ага
>но у меня мои реализации kevent работают, а вы со своими пока
>что концы с концами смести не можете, почуствуйте разницу

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

>->data как и ->udata для пользователя, и пользователь их устанавливает или убирает

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

>[оверквотинг удален]
>        } else {
>            kev->fflags = 0;
>            kev->data = 0;
>        }
>#else
>        kev->fflags = 0;
>        kev->data = 0;
>#endif
>
>показательно.. да... особенно NGX_HAVE_*

Конечно показательно, вы не только маны читать не умеете но и код. Этот кусок не про сокеты.
+ все 3 живые BSD как-бы HAVE
>тогда желаю вам разобраться с ваши не пониманием самим, благо дело код
>BSD открыт вместе с реализацией kevent

Праблема была решена еще позавчера. Но вы такой смешной, что мне не остановиться)

>
>Праблема была решена еще позавчера. Но вы такой смешной, что мне не
>остановиться)

смейтесь дальше)
тешите свое само любие? или повышаете ЧСВ?

/засим откланяюсь, теште себя сами

>смейтесь дальше)
>тешите свое само любие? или повышаете ЧСВ?

Помоему это пытались сделать вы за мой счет, но сели в лужу.

>/засим откланяюсь, теште себя сами

Извините если обидел.

>>смейтесь дальше)
>>тешите свое само любие? или повышаете ЧСВ?
>
>Помоему это пытались сделать вы за мой счет, но сели в лужу.
>

да нет
просто мы разговаривали о разных механизмах kevent
я не понял вашего, вы моего
но оба они присутсвуют в kevent
в моем механизме ->data не используется вообще

и да, сокеты у вас блокирующие?

>
>>/засим откланяюсь, теште себя сами
>
>Извините если обидел.

)

>просто мы разговаривали о разных механизмах kevent
>я не понял вашего, вы моего
>но оба они присутсвуют в kevent
>в моем механизме ->data не используется вообще

Наверное зря, как раз там и даются интересные возможности.
Например упомянутый вами NOTE_LOWAT позволяет не дергаться пока клиент не пришлет data байт.
Или тот же accept(). Согласитесь что открутить accept() в цикле data раз выгодней чем тоже число акцептов по одному + передергивание kevent() на каждый в вашей модели.

>и да, сокеты у вас блокирующие?

Нет конечно.
Кстати на *BSD тоже повод для экономии сискола т.к. O_NONBLOCK наследуется от listen() сокета.

>>просто мы разговаривали о разных механизмах kevent
>>я не понял вашего, вы моего
>>но оба они присутсвуют в kevent
>>в моем механизме ->data не используется вообще
>
>Наверное зря, как раз там и даются интересные возможности.
>Например упомянутый вами NOTE_LOWAT позволяет не дергаться пока клиент не пришлет data
>байт.

не соглашусь с вами
пока клинет не пришлет хотя бы что то
kevent не сработает, и выдаст таймаут по которому ожидает (в параметрах kevent)
на неблокирующих сокетах это колосальный профит

>Или тот же accept(). Согласитесь что открутить accept() в цикле data раз
>выгодней чем тоже число акцептов по одному + передергивание kevent() на
>каждый в вашей модели.
>

при неблокирующем сокете совсем другая логика
можно добавить в очередь kevent, 10000 сокетов и более (65536 лимит)
и обработать сразу в один присест не while () kevent, как вы говорите
а while () data[]
что в двойне профит

>>и да, сокеты у вас блокирующие?
>
>Нет конечно.

а ну тогда понятно

>Кстати на *BSD тоже повод для экономии сискола т.к. O_NONBLOCK наследуется от
>listen() сокета.

вообщем итоги,и ваши kevent заработали
и мои уже более пары лет не дают збоя

и что то мне подсказывает чутье, что если nginx переделать по моей модели работы kevent
то выиграш в производительности может подняться в разы

>не соглашусь с вами
>пока клинет не пришлет хотя бы что то
>kevent не сработает, и выдаст таймаут по которому ожидает (в параметрах kevent)
>на неблокирующих сокетах это колосальный профит

Сузим рамки. Неблокирующиеся сокеты, TCP.
Смотрите. по дефолту kevent будет дергаться на каждую порцию пакетов в рамках TCP таймаута. Т.е. в определенной ситуации kevent() будет нас дергать на каждый байт.
Этот флаг позволяет задать минимум принятых данных при котором event считается сработавшим.

>при неблокирующем сокете совсем другая логика
>можно добавить в очередь kevent, 10000 сокетов и более (65536 лимит)
>и обработать сразу в один присест не while () kevent, как вы
>говорите
>а while () data[]
>что в двойне профит

вы так и не поняли)
тут ваш код и любой другой не отличаются, реализация может быть любой но схема всегда одна:
for (;;) {
  n = kevent(kq, *changelist, nchanges, *eventlist, nevents, *timeout);
  for (i = 0; i < n; i++) {
    switch(eventlist[i]->filter){
    ...
    case EVFILT_READ:
      /*
       * Пусть тут мы поймали event на listen() сокете.
       * Зовем accept().
       * eventlist[i]->data = сколько раз мы можем сделать accept() без EWOULDBLOCK.
       */
    ...
    }
  }
}

Я вам пытаюсь объяснить, что kevent() в event'e для listen() сокета информирует о числе входящих конектов, готовых к accept. Которые вы обработаете по 1. проходя каждый раз
через вызов kevent(), а я [да да и nginx) через for (j = 0; j<eventlist[i]; j++) accept();

>и что то мне подсказывает чутье, что если nginx переделать по моей
>модели работы kevent
>то выиграш в производительности может подняться в разы

Извините, я не в коей мере не хочу вас обидеть, но только упасть, не в разы, но %20.

>через вызов kevent(), а я [да да и nginx) через for (j = 0; j<eventlist[i]; j++) accept();

Пора спать. следует читать for (j = 0; j<eventlist[i]->data; j++) accept();

>[оверквотинг удален]
>>пока клинет не пришлет хотя бы что то
>>kevent не сработает, и выдаст таймаут по которому ожидает (в параметрах kevent)
>>на неблокирующих сокетах это колосальный профит
>
>Сузим рамки. Неблокирующиеся сокеты, TCP.
>Смотрите. по дефолту kevent будет дергаться на каждую порцию пакетов в рамках
>TCP таймаута. Т.е. в определенной ситуации kevent() будет нас дергать на
>каждый байт.
>Этот флаг позволяет задать минимум принятых данных при котором event считается сработавшим.
>

для этих целей настраиваеться tcp окно уже в самой системе(тюнинг системы вообще делается)
но реальных ситуаций когда должны передаваться огромные данные
а начинают передаваться по байту
я никогда не сталкивался

>[оверквотинг удален]
>>при неблокирующем сокете совсем другая логика
>>можно добавить в очередь kevent, 10000 сокетов и более (65536 лимит)
>>и обработать сразу в один присест не while () kevent, как вы
>>говорите
>>а while () data[]
>>что в двойне профит
>
>вы так и не поняли)
>тут ваш код и любой другой не отличаются, реализация может быть любой
>но схема всегда одна:

согласен

>[оверквотинг удален]
>  for (i = 0; i < n; i++) {
>    switch(eventlist[i]->filter){
>    ...
>    case EVFILT_READ:
>      /*
>       * Пусть тут мы поймали
>event на listen() сокете.
>       * Зовем accept().
>       * eventlist[i]->data = сколько раз мы можем сделать accept() без EWOULDBLOCK.
>       */

         зачем так усложнять?
         если в udata можно передать адресс процедуры еще на этапе EV(ADD, some_accept,..
         а здесь уже звать эту процедуру
         ->udata();
         которая и сделает accept и остальное что надо, к примеру уже добавит
         дополнительные EV(ADD, some_recv,....

>    ...
>    }
>  }
>}
>
>Я вам пытаюсь объяснить, что kevent() в event'e для listen() сокета информирует

я понял
но смысла и профита в этом не вижу
пока ваш фильтр с вашей логикой будет информировать вас
моя логика будет уже обрабатывать

>о числе входящих конектов, готовых к accept. Которые вы обработаете по
>1. проходя каждый раз
>через вызов kevent(), а я [да да и nginx) через for (j
>= 0; j<eventlist[i]; j++) accept();

что еще раз?
а я это запустил еще в функции some_accept, смотрите выше

>
>
>>и что то мне подсказывает чутье, что если nginx переделать по моей
>>модели работы kevent
>>то выиграш в производительности может подняться в разы
>
>Извините, я не в коей мере не хочу вас обидеть, но только
>упасть, не в разы, но %20.

я все же останусь при своем мнении
потому что мне нет смысла получать дополнительный евент с data что бы знать количество ожидающих listen
я их уже на этом этапе буду обрабатывать

без дополнительного вызова kevent

чего то я тоже уже под устал.

>для этих целей настраиваеться tcp окно уже в самой системе(тюнинг системы вообще
>делается)

Пардонте, но прибить гвоздями размер tcp window не возможно.

>но реальных ситуаций когда должны передаваться огромные данные
>а начинают передаваться по байту
>я никогда не сталкивался

Эм... вы никогда не видели как медлено и печально DDOSят веб сервера?
Но суть опять же не в этом, а в том что если сервер заранее знает сколько данных нужно получить, то он может использую эту возможность (NOTE_LOWAT) не тратить ресурсы на лишние вызовы read().

>         зачем так усложнять?
>
>         если в udata
>можно передать адресс процедуры еще на этапе EV(ADD, some_accept,..
>         а здесь уже
>звать эту процедуру
>         ->udata();
>         которая и сделает
>accept и остальное что надо, к примеру уже добавит
>         дополнительные EV(ADD, some_recv,....

Да какая разница, зовете вы сискол напрямую или через обертку. Это детали реализации.
Да и сложностей я тут не вижу. Вы все равно должны проверять eventlist[i]->filter хотябы 1 раз [а вдруг там EV_ERROR получился], либо иметь лишний вызов kevent для установки changelist на каждый добавляемый эвент.

>а я это запустил еще в функции some_accept, смотрите выше

Простите, но почему-то не верю) Вы выше писали, что не используете поле data, а крутить accept пока не получим EWOULDBLOCK как-то не комильфо.

>потому что мне нет смысла получать дополнительный евент с data что бы
>знать количество ожидающих listen

Ну где, где вы там углядели доп. event????
Там ровно один event на каждый сокет который мы слушаем, возвращающий нужное число. Да и у вас тоже оно возвращается хотите вы этого или нет, вот только вы его упорно игнорируете)
К тому же цена 1 или 10 эвентов для kqueue стремиться к 0 по сравнению с одним лишним сисколом.

>[оверквотинг удален]
>>делается)
>
>Пардонте, но прибить гвоздями размер 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 по сравнению с одним лишним сисколом.

>с ДДосом боряться на уровне системы а не в реализациях клиент <->серверных приложениях

Я просто вам привел реальный пример таких ситуаций.

>даже при ~100 коротких ДДОс
>мне не накладно (если алгоритм программы оптимизированый) пробежаться read, close, по некорректных
>запросах

Они абсолютно корректны. Только медленные, соотвественно дропать таких клиентов не корректно. Причем не обязательно по вине клиента. Например при большой нагрузке в системе будет точно такое же поведение.

>я не использую ->data
>я использую ->udata

это теплое и мягкое.
data параметры/результаты фильтров
udata - пользовательская константа.

>ок. вы меня пытаетесь убедить что в ->data возращаеться количество ожидающих listen ?
>что бы потом по этим while ( ->data --) accept пробежаться?

Уже не пытаюсь)
Пытаюсь понять ваше утверждение, что вы делаете также не использую эту информацию.