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

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

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

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

Posted via ActualForum NNTP Server 1.5

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

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

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

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

Posted via ActualForum NNTP Server 1.5

alekcvp,

т.к. известно что клиентов у тебе немного, не мудри и делай просто по треду на клиента.

alekcvp
Траффик между ними не большой, но соединения должны висеть постоянно. то делать по потоку на каждого тоже не хочется (в пике их может быть до 500).

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

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

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

Через асинхронку может оказаться эффективней и менее ресурсоемко, но отнюдь не проще.

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

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

Ок, спасибо, попробую через кучу потоков. К тому же 500 - это крайний случай, более частый - это 60-70.

А насколько оперативно клиенты должны общаться с сервером ?
Как насчет того, чтобы клиенты периодически: раз в X секунд, обращались к серверу и спрашивали его: нет ли для меня указаний от консолей ?

alekcvp,

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

Sinemurius
А насколько оперативно клиенты должны общаться с сервером ? Как насчет того, чтобы клиенты периодически: раз в X секунд, обращались к серверу и спрашивали его: нет ли для меня указаний от консолей ?

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

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