SOMAXCONN

← →
Nucer (2008-01-26 18:06) [0]

Вот наткнулся на такую вещь в WinSock:
SOMAXCONN = 5;
Получается в очереди на подключение одновременно находиться могут только 5 клиентов?

По-моему это очень маленькое значение...
Можно ли в Listen указывать число больше пяти?

← →
Сергей М. © (2008-01-26 18:20) [1]

можно.
но не нужно, если не понимаешь, откуда берется эта пятерка

← →
Nucer (2008-01-26 18:30) [2]

Откуда берется - не понимаю. Она тупо прописана в winsock.pas. В msdn написано, что используйте SoMaxConn, но способа узнать конкретное значение нет.

http://msdn2.microsoft.com/en-us/library/ms739168(VS.85).aspx

The maximum length of the queue of pending connections. If set to SOMAXCONN, the underlying service provider responsible for socket s will set the backlog to a maximum reasonable value. There is no standard provision to obtain the actual backlog value.

Вот и не понятно с чего вдруг в winsock.pas прописано именно SOMAXCONN = 5; Может это значение актуально для первой версии библиотеки winsock, а во второй константу можно значительно увеличить?
К примеру, значение 30 - всегда ли будет работать?

← →
Сергей М. © (2008-01-26 19:05) [3]

> К примеру, значение 30

А нахрена ? И почему не 300 и не 3000000 ?

← →
Nucer (2008-01-26 22:02) [4]

Надо повысить, т.к. сервер сбрасывает соединения чего делать не должен (нагрузка не такая уж и большая, около 50 соединений в секунду). Насколько я понял, узкое горло - именно SoMaxConn. Посмотрел модуль IdWinSock2.pas, там:
somaxconn = $7fffffff;

В итоге вопрос, какое можно установить значение? Я так понимаю вместо SoMaxConn должна использоваться какая-то зарезервированная константа (типа $7fffffff), а не "5", как прописано в winsock.pas.

← →
Сергей М. © (2008-01-28 10:09) [5]

> Nucer (26.01.08 22:02) [4]

Без ориентации на конкретную ОС и конкретную же версию используемого сокет-провайдера (в Winsock см. WSAStartup) разговор не имеет смысла.

Почитай это
http://rsdn.ru/Forum/message/267790.flat.aspx

Кр.того, подозреваю, что алгоритм, исполняемый твоим слушающим потоком, низкоэффективен и не оптимизирован, так что пляски с бубном вокруг backlog queue начинать рановато.

← →
Nucer (2008-01-28 19:53) [6]

Я уверен, что алгоритм не эффективен. В том же потоке, в котором вызывается функция Accept, выполняются SQL запросы к СУБД. Но проще увеличить SoMaxConn (временная мера), чем полностью переписать сервер с нуля.

← →
Nucer (2008-01-28 19:53) [7]

ОС - Windows 2003 Server x64

> проще увеличить SoMaxConn (временная мера), чем полностью
> переписать сервер с нуля

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

Nucer (28.01.08 19:53) [6]
В том же потоке, в котором вызывается функция Accept, выполняются SQL запросы к СУБД
вот и причина!
поток Accept должен породить другой поток и уже в этом новом потоке делай свой SQL

SOMAXCONN Найти похожие ветки