форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы Программирование под UNIX (Сеть, сокеты)
Изначальное сообщение		[ Отслеживать ]

"kqueue/kevent"	+/–
Сообщение от guest (??) on 07-Июн-10, 10:20
Цитата из мана про 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()?
Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "kqueue/kevent"	+/–
Сообщение от анонимус (??) on 07-Июн-10, 22:29
>Цитата из мана про 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() перефразируйте ваш вопрос, он не ясен
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	2. "kqueue/kevent"	+/–
	Сообщение от guest (??) on 07-Июн-10, 23:01
	>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("да, так бывает")
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	3. "kqueue/kevent"	+/–
	Сообщение от анонимус (??) on 09-Июн-10, 22:23
	>[оверквотинг удален] >ок. >Вопрос: может ли значение возвращаемое 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 и разберите его возможно после этого у вас все прояснитсья
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	4. "kqueue/kevent"	+/–
	Сообщение от guest (??) on 10-Июн-10, 10:22
	>у вас неправильное представление о том как использовать kevent & socket >возьмите любой работающий код, к примеру inetd с freebsd и разберите его Вы бы для приличия хоть одним глазом RTFS перед тем как советовать сделали, inetd select based во фре. >возможно после этого у вас все прояснитсья Проясняется потихоньку, отвечу сам себе: FreeBSD: так не бывает. OpenBSD: бывает. google kern.sominconn NetBSD: так не бывает.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	5. "kqueue/kevent"	+/–
	Сообщение от анонимус (??) on 10-Июн-10, 11:27
	>>у вас неправильное представление о том как использовать 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 (судя по вашему псевдо коду)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	6. "kqueue/kevent"	+/–
	Сообщение от guest (??) on 10-Июн-10, 20:44
	>ошибся, не во фре а в netbsd Спасибо, посмотрел. Там нет интересовавшего меня цикла с accept(), правда для inetd он наверное и не нужен.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	7. "kqueue/kevent"	+/–
	Сообщение от анонимус (??) on 10-Июн-10, 21:13
	>>ошибся, не во фре а в netbsd > >Спасибо, посмотрел. Там нет интересовавшего меня цикла с accept(), правда для inetd >он наверное и не нужен. зачем в accept циклы? man kevent res = kevent возращает количество данных с наступившими собитыями что вы там в ->data > BACKLOG сравниваете я ума не приложу
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	8. "kqueue/kevent"	+/–
	Сообщение от guest (??) on 10-Июн-10, 21:39
	> что вы там в ->data > BACKLOG сравниваете я ума не приложу ман прочтите чтоли
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	9. "kqueue/kevent"	+/–
	Сообщение от анонимус (??) on 10-Июн-10, 21:53
	>> что вы там в ->data > BACKLOG сравниваете я ума не приложу > >ман прочтите чтоли поучите меня что ли у меня клиент серверных приложений на kevent поболее будет давайте выдержку из мана, в которой вы не можете разобраться
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	10. "kqueue/kevent"	+/–
	Сообщение от guest (??) on 10-Июн-10, 21:56
	>давайте выдержку из мана, в которой вы не можете разобраться 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. Помочь перевести или сами осилите?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	11. "kqueue/kevent"	+/–
	Сообщение от анонимус (??) on 10-Июн-10, 22:23
	ну теперь все совсем понятно вы перевели неправильно data не имелась ввиду ->data а имелось ввиду результат выполнения функции   res = kevent(..., &data[0], ....) если res отличный от нуля и -1 значит в res количество событий для обработки, а в data[] массив сработавший EVENT это ясно и из любого примера использования kevent который вы так упорно не хотите найти и посмотреть взять хотя бы всем известный nginx
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	12. "kqueue/kevent"	+/–
	Сообщение от guest (??) on 10-Июн-10, 22:46
	>ну теперь все совсем понятно >вы перевели неправильно >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
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	13. "kqueue/kevent"	+/–
	Сообщение от анонимус (??) on 10-Июн-10, 23:03
	>Слава Богу, что стандарты и маны пишете не вы, а адекватные люди. > сьязвили ага но у меня мои реализации 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
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	14. "kqueue/kevent"	+/–
	Сообщение от анонимус (??) on 10-Июн-10, 23:13
	обратитесь к автору nginx, поверте он хороший человек надеюсь он вас вразумит
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	15. "kqueue/kevent"	+/–
	Сообщение от guest (??) on 10-Июн-10, 23:20
	>сьязвили ага >но у меня мои реализации 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 Праблема была решена еще позавчера. Но вы такой смешной, что мне не остановиться)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	16. "kqueue/kevent"	+/–
	Сообщение от анонимус (??) on 10-Июн-10, 23:26
	> >Праблема была решена еще позавчера. Но вы такой смешной, что мне не >остановиться) смейтесь дальше) тешите свое само любие? или повышаете ЧСВ? /засим откланяюсь, теште себя сами
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	17. "kqueue/kevent"	+/–
	Сообщение от guest (??) on 10-Июн-10, 23:32
	>смейтесь дальше) >тешите свое само любие? или повышаете ЧСВ? Помоему это пытались сделать вы за мой счет, но сели в лужу. >/засим откланяюсь, теште себя сами Извините если обидел.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	18. "kqueue/kevent"	+/–
	Сообщение от анонимус (??) on 10-Июн-10, 23:39
	>>смейтесь дальше) >>тешите свое само любие? или повышаете ЧСВ? > >Помоему это пытались сделать вы за мой счет, но сели в лужу. > да нет просто мы разговаривали о разных механизмах kevent я не понял вашего, вы моего но оба они присутсвуют в kevent в моем механизме ->data не используется вообще и да, сокеты у вас блокирующие? > >>/засим откланяюсь, теште себя сами > >Извините если обидел. )
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	19. "kqueue/kevent"	+/–
	Сообщение от guest (??) on 10-Июн-10, 23:47
	>просто мы разговаривали о разных механизмах kevent >я не понял вашего, вы моего >но оба они присутсвуют в kevent >в моем механизме ->data не используется вообще Наверное зря, как раз там и даются интересные возможности. Например упомянутый вами NOTE_LOWAT позволяет не дергаться пока клиент не пришлет data байт. Или тот же accept(). Согласитесь что открутить accept() в цикле data раз выгодней чем тоже число акцептов по одному + передергивание kevent() на каждый в вашей модели. >и да, сокеты у вас блокирующие? Нет конечно. Кстати на *BSD тоже повод для экономии сискола т.к. O_NONBLOCK наследуется от listen() сокета.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	20. "kqueue/kevent"	+/–
	Сообщение от анонимус (??) on 11-Июн-10, 00:01
	>>просто мы разговаривали о разных механизмах 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 то выиграш в производительности может подняться в разы
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	21. "kqueue/kevent"	+/–
	Сообщение от guest (??) on 11-Июн-10, 00:35
	>не соглашусь с вами >пока клинет не пришлет хотя бы что то >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.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	22. "kqueue/kevent"	+/–
	Сообщение от guest (??) on 11-Июн-10, 00:38
	>через вызов kevent(), а я [да да и nginx) через for (j = 0; j<eventlist[i]; j++) accept(); Пора спать. следует читать for (j = 0; j<eventlist[i]->data; j++) accept();
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	23. "kqueue/kevent"	+/–
	Сообщение от анонимус1 on 11-Июн-10, 02:12
	>[оверквотинг удален] >>пока клинет не пришлет хотя бы что то >>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 чего то я тоже уже под устал.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	24. "kqueue/kevent"	+/–
	Сообщение от guest (??) on 11-Июн-10, 09:53
	>для этих целей настраиваеться 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 по сравнению с одним лишним сисколом.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	25. "kqueue/kevent"	+/–
	Сообщение от анонимус1 on 11-Июн-10, 12:11
	>[оверквотинг удален] >>делается) > >Пардонте, но прибить гвоздями размер 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 по сравнению с одним лишним сисколом.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	26. "kqueue/kevent"	+/–
	Сообщение от guest (??) on 11-Июн-10, 13:35
	>с ДДосом боряться на уровне системы а не в реализациях клиент <->серверных приложениях Я просто вам привел реальный пример таких ситуаций. >даже при ~100 коротких ДДОс >мне не накладно (если алгоритм программы оптимизированый) пробежаться read, close, по некорректных >запросах Они абсолютно корректны. Только медленные, соотвественно дропать таких клиентов не корректно. Причем не обязательно по вине клиента. Например при большой нагрузке в системе будет точно такое же поведение. >я не использую ->data >я использую ->udata это теплое и мягкое. data параметры/результаты фильтров udata - пользовательская константа. >ок. вы меня пытаетесь убедить что в ->data возращаеться количество ожидающих listen ? >что бы потом по этим while ( ->data --) accept пробежаться? Уже не пытаюсь) Пытаюсь понять ваше утверждение, что вы делаете также не использую эту информацию.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема