Реализация сервера в службе

alekcvp
Дата: 30.10.2019 19:42:43
Делаю сейчас приложение для управления некоторыми компами. Схема такая: Консоль (1-2) <=> Сервер (1) <=> Агенты (много). Траффик между ними не большой, но соединения должны висеть постоянно. Чтобы не заморачиваться использую стандартные сокеты (dclsocketsXXX).

И если с консолью и агентами всё понятно, т.к. там и там GUI и поток исполнения один, то вот с сервером есть вопрос: приложение на сервере - это служба, оно кэширует у себя состояние всех агентов и управляет ими по командам с консоли. GUI у него нет. Т.к. клиентов дофига, то делать по потоку на каждого тоже не хочется (в пике их может быть до 500). Как лучше всего это реализовать с т.з. простоты и минимизации возможных граблей - через асинхронный режим, с организацией свой обработки сообщений в службе или в блокирующем режиме через пул потоков по N-ное количество соединений на поток?..
Dimitry Sibiryakov
Дата: 30.10.2019 19:45:10

Я бы лично использовал WinSock функции в неблокирующем режиме.

Posted via ActualForum NNTP Server 1.5

alekcvp
Дата: 30.10.2019 19:46:43
Dimitry Sibiryakov
Я бы лично использовал WinSock функции в неблокирующем режиме.

Но тогда придётся делать свою очередь обработки сообщений, так ведь?
Dimitry Sibiryakov
Дата: 30.10.2019 19:52:37

alekcvp
Но тогда придётся делать свою очередь обработки сообщений, так ведь?

Нет, она в службе совершенно ни к чему.

Posted via ActualForum NNTP Server 1.5

ёёёёё
Дата: 30.10.2019 19:53:44
alekcvp,

т.к. известно что клиентов у тебе немного, не мудри и делай просто по треду на клиента.
rgreat
Дата: 30.10.2019 19:56:50
alekcvp
Траффик между ними не большой, но соединения должны висеть постоянно.

то делать по потоку на каждого тоже не хочется (в пике их может быть до 500).

Если учесть что траффик не большой то 500 соединений это не так много.
Хотя ты не уточнил что значит "не большой".
И какова прочая ресурсоемкость от одного клиента на сервере?

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

С точки зрения простоты и надежности лучше таки 500 потоков с блокирующим сокетом.

Через асинхронку может оказаться эффективней и менее ресурсоемко, но отнюдь не проще.
alekcvp
Дата: 30.10.2019 20:07:22
rgreat
Хотя ты не уточнил что значит "не большой".
И какова прочая ресурсоемкость от одного клиента на сервере?

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

Ок, спасибо, попробую через кучу потоков. К тому же 500 - это крайний случай, более частый - это 60-70.
Sinemurius
Дата: 30.10.2019 20:31:03
А насколько оперативно клиенты должны общаться с сервером ?
Как насчет того, чтобы клиенты периодически: раз в X секунд, обращались к серверу и спрашивали его: нет ли для меня указаний от консолей ?
ёёёёё
Дата: 30.10.2019 20:38:17
alekcvp,

главное - сильно не выёживаться. Я вот разработал "архигениальную" архитектуру, где каждый пользователь гарантированно может иметь не более одного коннекта к серверу, ибо так было многократно заявлено, а потом выяснилось что "в исключительных случаях - два" , а потом и "три"... тьфу.
alekcvp
Дата: 30.10.2019 20:56:34
Sinemurius
А насколько оперативно клиенты должны общаться с сервером ?
Как насчет того, чтобы клиенты периодически: раз в X секунд, обращались к серверу и спрашивали его: нет ли для меня указаний от консолей ?

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

P.S: O_o на sql.ru теперь можно редактировать сообщения О_О