Доброго времени, уважаемые форумчане!
Прошу помощи в следующем. Имеем "отладочное" приложение, которое содержит TServerSocket, работающий в неблокирующем режиме (stNonBlocking) и принимающий данные от кучи разных устройств/локальных клиентских программ и прочее. Все отлично работает, срабатывает событие OnClientRead(), выполняю обработку и, при необходимости, отправку данных при помощи SendText(). В случае, если данные были разбиты на части во время их передачи, OnClientRead() вызывается для каждой части по порядку и проблем тоже нет.



Затем, все это дело я оформил как службу - штатный TService. И появилась такая проблема - все работает примерно в течение часа, затем перестает работать. Служба запущена всегда, остановок и исключений нет. Сделал свой собственный простой и примитивный лог - вижу, что после определенного количества подключений (около 100 активных sockets) перестает срабатывать событие OnClientRead(). То есть, клиент подключается, подключение проходит, но событие уже не срабатывает. При перезапуске службы, разумеется, все начинает работать, опять-таки до поры до времени. Если кто сталкивался с чем-то подобным, пуду премного признателен.
Может быть, дело в том, что нельзя использовать stNonBlocking внутри службы? Программа была идеально отлажена именно в этом режиме работы сервера.

DmSer,
В том и дело, что нет никаких ShowMessage(), как будто бы есть какое-то ограничение на количество подключений (что-то типа ThreadCacheSize - но это для блокирующего режима и работы с потоками, а здесь все в главном потоке, ибо обработка очень быстрая).
Пока поставил в таймере такой "костыль" с интервалом на 1 час (3600000 мс).



Пока все это работает, но это не дело совсем, конечно...

DmSer,
Теоретически не должно быть зависаний, ибо действующие подключения еще некоторое время работают, потом вообще умирает все. Кстати, вышеприведенный "костыль" не помог - все равно перестает срабатывать событие, я это вижу по своему кустарному логу и по факту того, что ответ SendText() перестает приходить через некоторое время (отправляю при помощи Packet Sender - эмулирую сообщение клиента). А каким образом TService может взаимодействовать с TServerSocket? Только запуск, остановка, обработка событий от TServerSocket.
Экземпляр TServerSocket создаю динамически в RunTime, ибо убрали их давно из палитры компонентов, так удобнее.

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

DmSer,
try... except все на месте, но все равно сейчас пытаюсь проверить на зависание/срабатывание Exception, может, где что упустил. В десктопе, правда, никаких исключений не выпадало, все обрабатывается.

DmSer,
Зависание маловероятно, ибо поставил таймер и он работает в главном потоке, вижу по логам, да и действующие подключения еще живут какое-то время и работает обмен данными, что видно при помощи сниффера и при отправке эмуляции пакета и получением ответа программой Packet Sender. Исключений тоже нет - проверил, да и не было в десктопе - там все чисто по исключениям, расставлены все try ... except/finally.
А что значит - кончились сокеты? В декстопе же не кончались, я там тысячи подключений делал и работало идеально. Здесь же после 100 - 150 активных подключений уже все падает. Причем обнаружил такую вещь, которая совсем лишила меня понимания - иногда после "зависания" снова начинает работать, будто переполняется/высвобождается какой-то глобальный ресурс. В десктопе ничего подобного не было.

Пока вижу только два варианта -
1. Отказаться от службы и юзать десктопный вариант. Прям совсем не хотелось бы, ибо десктоп на сервере зло (нужен логин на сервер), а служба очень удобная вещь, сама запускается, работает в фоне, ресурсов минимум, не требует входа в систему - идеальный вариант для такого сервера.
2. Отказаться от TServerSocket и использовать что-то иное.

wadman,
Сейчас гляну...

Zelius,
Подключения постоянные - живут столько, сколько позволит сеть и условия. Там, где GPRS - рвется немного чаще, так как, по моему, сотовые операторы как-то регламентируют время жизни сессии. Там, где локалка - могут и сутками висеть

wadmanПальцем в небо: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnableConnectionRateLimiting - должно быть 0.
Вовсе нет такого параметра в этой ветви...

Zeliusoklalex,
посмотри netstat все же, сколько там висит соединений и в каком состоянии... может залипают соединения
Соединений там всегда очень много - некоторые из тех, что по GPRS, могут находиться в TIME_WAIT, это нормально для них в целом, потом, как я понимаю, они умирают и клиент переподключается. Те, которые по локальной сети или по LTE, там у всех ESTABLISHED всегда.

YuRockoklalexЗависание маловероятно, ибо поставил таймер и он работает в главном потоке, вижу по логамЗначит - точно MessageBox (или какое другое модальное окно) висит.
Он не мешает отрабатывать таймеру.
Если бы все было так просто ) Я этот код уже вверх дном перевернул, в десктопе запускал по-разному... Попробую еще поискать. Может, сам TServerSocket что выдает, но я его сообщения подавляю (ErrorCode задаю 0), а в лог себе вывожу перед этим

YuRockoklalexDmSer,
try... except все на месте, но все равно сейчас пытаюсь проверить на зависание/срабатывание Exception, может, где что упустил. В десктопе, правда, никаких исключений не выпадало, все обрабатывается.В "десктопе" были совсем другие права.
У службы, например, нет прав на сетевые шары, которые были у твоего "десктопа". И многое еще отличается. Ты можешь не видеть каких-то окон, объектов...
Может, в этом причина.
Вот про это думал тоже и не раз . Службу пробовал запускать, как от системной учетной записи, так и как сетевую службу, так и от имени администратора (задав логин и пароль в настройках службы). Ничего не помогает. Десктоп при этом запускал с обычными правами, как калькулятор. Да и служба там простая - парсит данные и сохраняет на отдельный локальный диск, никаких прав особых ей не требуется.

DmSerYuRockпропущено...
Может, при записи в лог какие проблемы.
Может, out of memory.
Может компонент глючит.
Я никогда не использовал TServerSocket в неблокирующем режиме - только в stThreadBlocking, но там работал вроде норм.
Хотя потом перешел на чистое апи и написал свой TServerSocket. Что-то раздражало и чего-то не хватало.

Тоже не использую. Работаю с Indy, там только блокирующий режим. Сотни постоянных подключений, работает годами, глюков не наблюдал. Если делать 32-разрядную прогу, то упрешься в лимит подключений из-за виртуальной памяти (особенно если 64-битная винда). Для 64-разрядной проги Indy будет без проблем держать тысячи подключений. ОЗУ при этом расходуется не более 64 КБ на подключение.
Вот, это отдельная часть этой оперы. Windows 10 Pro и все приложения строго 64-битные, написаны на Delphi 10.3, как и многое другое. Сам работаю с Indy и все гладко, но есть один момент - там и клиенты, и сервер написаны мной, ReadStream/WriteStream и все дела. TIdTCPClient/Server сам пишет в сообщение размерность данных, поток любого размера прекрасно передается по сети.
А с этим сервером проблема. Там многое разработано не мной, там контроллеры, там старые программы, написанные еще на Visual Studio 5 на MFC и многие другие прелести жизни. Они не пишут в протокол размерность данных. Как в этом случае правильно работать с IdTCPServer. Он вызывает событие OnExecute, потом надо как-то принять весь входной буфер, не зная его размера, ибо сообщения более 1 КБ "по дороге" фрагментируются . Затем, надо как-то иметь доступ к этим подключениям, чтобы в любой момент отправить им в активный сокет данные, найдя этот сокет по его Handle. Если все это можно запилить на IdTCPServer, подскажите, как.

YuRockoklalex надо как-то принять весь входной буфер, не зная его размера, ибо сообщения более 1 КБ "по дороге" фрагментируются Фрагментироваться могут любые буффера.
Принимать, собирая и разбивая на пакеты, необходимо через свой протокол (или чужой, предназначенный для такого).
Вопрос уже был конкретно по Indy адресован человеку )
TIdTCPServer заточен под прием данных, зная их размерность.
В TServerSocket есть событие OnClientRead - оно срабатывает подряд для одного сокета до тех пор, пока весь буфер не примет.



Поэтому получается "собрать" сообщение и привязать его к хэндлу сокета, ибо сокет нам передается в параметрах. А дальше парсинг и соединение висит, пока не придет следующий пакет. О размерности данных я понятия не имею - просто принимаю весь входной буфер. Вопрос в том, как это сделать на TIdTCPServer... если переходить на него

Zelius,
Сервер пишет, клиент ловит и отмечает, что принято. Там логика четкая. Дебажить службы умею, только вот проявляется это уже на реальном сервере, где счет на сотни и тысячи подключений, там не отдебажить никак и ставить туда не хотелось бы ничего

Zeliusoklalex,
тогда только логирование, включая потроха TServerSocket, затянуть в проект, напихать во все места...
И так перетрес его весь, да и в десктоп-варианте он работает ведь. Думаю, проще перейти с него на что-нибудь другое, попробовать TIdTCPServer, но тогда выше написанное мной в силе

oklalexZeliusoklalex,
тогда только логирование, включая потроха TServerSocket, затянуть в проект, напихать во все места...
И так перетрес его весь, да и в десктоп-варианте он работает ведь. Думаю, проще перейти с него на что-нибудь другое, попробовать TIdTCPServer, но тогда выше написанное мной в силе
Indy кстати тоже в свое время перевернул вверх дном исходник, кое-что допилил под себя. Речь о версии 10.

YuRock,
Это да, буду сейчас дальше копать, но про переход на TIdTCPServer тоже было бы интересно сделать

oklalexDmSerпропущено...
Тоже не использую. Работаю с Indy, там только блокирующий режим. Сотни постоянных подключений, работает годами, глюков не наблюдал. Если делать 32-разрядную прогу, то упрешься в лимит подключений из-за виртуальной памяти (особенно если 64-битная винда). Для 64-разрядной проги Indy будет без проблем держать тысячи подключений. ОЗУ при этом расходуется не более 64 КБ на подключение.
Вот, это отдельная часть этой оперы. Windows 10 Pro и все приложения строго 64-битные, написаны на Delphi 10.3, как и многое другое. Сам работаю с Indy и все гладко, но есть один момент - там и клиенты, и сервер написаны мной, ReadStream/WriteStream и все дела. TIdTCPClient/Server сам пишет в сообщение размерность данных, поток любого размера прекрасно передается по сети.
А с этим сервером проблема. Там многое разработано не мной, там контроллеры, там старые программы, написанные еще на Visual Studio 5 на MFC и многие другие прелести жизни. Они не пишут в протокол размерность данных. Как в этом случае правильно работать с IdTCPServer. Он вызывает событие OnExecute, потом надо как-то принять весь входной буфер, не зная его размера, ибо сообщения более 1 КБ "по дороге" фрагментируются . Затем, надо как-то иметь доступ к этим подключениям, чтобы в любой момент отправить им в активный сокет данные, найдя этот сокет по его Handle. Если все это можно запилить на IdTCPServer, подскажите, как.

DmSeroklalexпропущено...

И так перетрес его весь, да и в десктоп-варианте он работает ведь. Думаю, проще перейти с него на что-нибудь другое, попробовать TIdTCPServer, но тогда выше написанное мной в силе

Я для этого использую конечный автомат.
В ход идут методы:
ClientSocket.Connection.Socket.InputBuffer.Size
ClientSocket.Connection.Socket.CheckForDataOnSource(50)
ClientSocket.Connection.Socket.ReadByte()
ClientSocket.Connection.Socket.InputBuffer.Extract()

Нужно также учитывать, что перед вызовом ClientSocket.Connection.Disconnect необходимо проверить ClientSocket.Connection.Socket.InputBuffer.Size и считать все имеющиеся байты.
Друзья, всем спасибо за ответы, мнения, комментарии, уделенное время!
С TServerSocket изрядно покопался, там достойно отдельной темы )) но ничего так не получилось ))
Решил переехать пока на Indy, ибо их неплохо знаю и с ними много приходилось работать. Итак, имеем TIdTCPServer:



При отправке сообщения на него оно приходит в OnExecute(), как и должно быть, затем я его там ловлю, как и советовал DmSer - примерно так:



Затем, специально подключив GPRS-канал, делаю передачу крупного (> 1 КБ) сообщения, чтобы вызвать фрагментацию сообщения. В этом случае сообщение снова приходит частями, для каждой из которых вызывается OnExecute() до тех пор, пока входной буфер не пуст. И тут есть очень сильная хотелка - как бы так "собрать" это сообщение в первом вызове OnExecute(), зациклив проверку буфера? Ибо здесь все, что делается в OnExecute(), выполняется в отдельном потоке и крайне не хотелось бы заморачиваться внешними глобальными списками/массивами и "сборкой" полного сообщения. Хотелось бы - чтобы все действия по приему и обработке одного сообщения "не покидали" этого отдельного потока. Пробовал сделать нечто такое (код очень грубый, экспериментально, не ругайте):



Отрабатывает, но при этом OnExecute() почему-то продолжает постоянно вызываться, хотя входной буфер пуст (разумеется, грузит ЦП и прочее). Само соединение при этом активно и должно таковым оставаться сколь угодно долго. Таким образом, возникает первый вопрос - как правильно реализовать эту простую логику? Длины входного сообщения я не знаю.

Дополню - OnExecute() всегда начинает вызываться постоянно, пока висит подключение. Хотя бы этого как-то можно избежать?

Друзья, всем огромное спасибо за внимание и идеи. Прошу прощения, что сразу не ответил. Проблема решилась, перенес на Indy, в который раз убеждаюсь, что это очень продуманная вещь. Вкратце - проблему нашел и тут выше ее уже примерно озвучивали - множество соединений висит в состоянии Time_Wait, обычный TServerSocket это не переваривает, они "висят вечно" и в итоге все останавливается. При большой нагрузке очень быстро. При переносе на Indy сделал ручную проверку, живое ли соединение, и если нет, отключаю. Кстати, у Indy и на этот счет есть штатное решение - SetKeepAliveValues(). Все принимается в одном вызове OnExecute(), спасибо DmSer огромное за то, что навели на правильную идею и привели прототипы необходимых функций.
При желании, можно 100% подобное реализовать и с TServerSocket, но уже не стал заморачиваться и строить велосипеды

Василий 2oklalexИ тут есть очень сильная хотелка - как бы так "собрать" это сообщение в первом вызове OnExecute(), зациклив проверку буфера?
Просто встань на место сервера и посмотри на сообщение с его т.зр. Как ему определить, что клиент отстрелялся с данными?

Либо длина в заголовке, либо сигнатура окончания. Можно еще по таймауту ждать, но это ламерство.
Согласен полностью, если бы так было сделано - эта тема бы не возникла ) но клиенты многие написаны не мной и так, как Господь на душу положит ( поэтому пришлось подстроить таймауты и работать в условиях тех ограничений, в которые поставлен (