|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
30.10.2019, 19:42
|
|||
|---|---|---|---|
Реализация сервера в службе |
|||
|
#18+
Делаю сейчас приложение для управления некоторыми компами. Схема такая: Консоль (1-2) <=> Сервер (1) <=> Агенты (много). Траффик между ними не большой, но соединения должны висеть постоянно. Чтобы не заморачиваться использую стандартные сокеты (dclsocketsXXX). И если с консолью и агентами всё понятно, т.к. там и там GUI и поток исполнения один, то вот с сервером есть вопрос: приложение на сервере - это служба, оно кэширует у себя состояние всех агентов и управляет ими по командам с консоли. GUI у него нет. Т.к. клиентов дофига, то делать по потоку на каждого тоже не хочется (в пике их может быть до 500). Как лучше всего это реализовать с т.з. простоты и минимизации возможных граблей - через асинхронный режим, с организацией свой обработки сообщений в службе или в блокирующем режиме через пул потоков по N-ное количество соединений на поток?.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.10.2019, 19:45
|
|||
|---|---|---|---|
|
|||
Реализация сервера в службе |
|||
|
#18+
Я бы лично использовал WinSock функции в неблокирующем режиме. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.10.2019, 19:46
|
|||
|---|---|---|---|
Реализация сервера в службе |
|||
|
#18+
Dimitry SibiryakovЯ бы лично использовал WinSock функции в неблокирующем режиме. Но тогда придётся делать свою очередь обработки сообщений, так ведь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.10.2019, 19:52
|
|||
|---|---|---|---|
|
|||
Реализация сервера в службе |
|||
|
#18+
alekcvpНо тогда придётся делать свою очередь обработки сообщений, так ведь? Нет, она в службе совершенно ни к чему. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.10.2019, 19:53
|
|||
|---|---|---|---|
Реализация сервера в службе |
|||
|
#18+
alekcvp, т.к. известно что клиентов у тебе немного, не мудри и делай просто по треду на клиента. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.10.2019, 19:56
|
|||
|---|---|---|---|
Реализация сервера в службе |
|||
|
#18+
alekcvpТраффик между ними не большой, но соединения должны висеть постоянно. то делать по потоку на каждого тоже не хочется (в пике их может быть до 500). Если учесть что траффик не большой то 500 соединений это не так много. Хотя ты не уточнил что значит "не большой". И какова прочая ресурсоемкость от одного клиента на сервере? Как лучше всего это реализовать с т.з. простоты и минимизации возможных граблей - через асинхронный режим, с организацией свой обработки сообщений в службе или в блокирующем режиме через пул потоков по N-ное количество соединений на поток?.. С точки зрения простоты и надежности лучше таки 500 потоков с блокирующим сокетом. Через асинхронку может оказаться эффективней и менее ресурсоемко, но отнюдь не проще. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.10.2019, 20:07
|
|||
|---|---|---|---|
Реализация сервера в службе |
|||
|
#18+
rgreatХотя ты не уточнил что значит "не большой". И какова прочая ресурсоемкость от одного клиента на сервере? Ну что-то типа управляющего соединения FTP: получить состояние, изменить параметры, передача сообщений о ходе выполнения длительных задач. Ок, спасибо, попробую через кучу потоков. К тому же 500 - это крайний случай, более частый - это 60-70. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.10.2019, 20:31
|
|||
|---|---|---|---|
|
|||
Реализация сервера в службе |
|||
|
#18+
А насколько оперативно клиенты должны общаться с сервером ? Как насчет того, чтобы клиенты периодически: раз в X секунд, обращались к серверу и спрашивали его: нет ли для меня указаний от консолей ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.10.2019, 20:38
|
|||
|---|---|---|---|
Реализация сервера в службе |
|||
|
#18+
alekcvp, главное - сильно не выёживаться. Я вот разработал "архигениальную" архитектуру, где каждый пользователь гарантированно может иметь не более одного коннекта к серверу, ибо так было многократно заявлено, а потом выяснилось что "в исключительных случаях - два" , а потом и "три"... тьфу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.10.2019, 20:56
|
|||
|---|---|---|---|
Реализация сервера в службе |
|||
|
#18+
SinemuriusА насколько оперативно клиенты должны общаться с сервером ? Как насчет того, чтобы клиенты периодически: раз в X секунд, обращались к серверу и спрашивали его: нет ли для меня указаний от консолей ? ... а человек на консоли, отдав команду сидит и несколько секунд ждёт пока она выполнится?.. Не думаю что это хороший вариант, ничто так не раздражает (меня, например) как "лагающий" без причины интерфейс у приложения. P.S: O_o на sql.ru теперь можно редактировать сообщения О_О ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.10.2019, 22:15
|
|||
|---|---|---|---|
|
|||
Реализация сервера в службе |
|||
|
#18+
Хм. А как осуществляется физическая связь между агентами и сервером ? Каждый агент на собственном компьютере в локальной сети ?или все агенты на одном компе ? Или каждый агент на устройстве подключенном к одной к wifi точке ? Или сервер на арендованном хосте, а агенты - это устройства в интернете ? На мой взгляд, ответ на этот вопрос имеет значение для выбора архитектуры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
30.10.2019, 23:58
|
|||
|---|---|---|---|
Реализация сервера в службе |
|||
|
#18+
SinemuriusХм. А как осуществляется физическая связь между агентами и сервером ? Каждый агент на собственном компьютере в локальной сети ? Агент = компьютер, сервер - в той же сети. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.10.2019, 07:00
|
|||
|---|---|---|---|
|
|||
Реализация сервера в службе |
|||
|
#18+
То есть каждый агент имеет уникальный ip-шник и поскольку есть контроль над сетью, то можете выбрать порт, в рамках которого будете общаться в сети. Тогда я бы сделал примерно так (я бы делал на Indy просто потому, что я с ним уже работал и знаю всякие нюансы, но Вы разумеется можете использовать синапс, сокеты и т.д.). На сервере компонент TIdTCPServer слушает порт. Агент запускается, открывает соединение с сервером и "регистрируется", то есть посылает серверу информацию о своем ip-шнике, времени запуска и еще какую нибудь идентифицирующую информацию: ну например имя пользователя ОС. И такую инфомацию агент посылает периодически, например раз в минуту, типа "я жив". После регистрации, агент создает собственный экземпляр TIdTCPServer и начинает слушать порт, то есть становится сервером. Вы из консоли хотите послать сообщение (команду) агенту с именем пользователя "Маша". Вы открываете сеанс соединения с сервером, посылаете ему информацию о сообщении и получателе. Сервер в рамках сеанса смотрит в своем списке: есть ли "живой" агент "Маша", получает его ip-шник и открывает уже сам сеанс соединения с TIdTCPServer на агенте "Маша", передает агенту необходимую информацию или команду и закрывает соединение с Машей. Затем передает в рамках соединения с консолью подтверждение о том, что сеанс с Машей прошел успешно, консоль получает эту информацию и закрывает соединение с сервером. Никаких открытых потоков и соединений держать не нужно. В момент соединения консоли с сервером Indy создаст поток для сеанса соединения с сервером и также будет создан поток для соединения сервера с агентом. Но это на короткое время. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.10.2019, 09:10
|
|||
|---|---|---|---|
Реализация сервера в службе |
|||
|
#18+
alekcvp, когда то делал такую же задачу. Из особенностей - агенты могли располагаться где угодно, у них мог отсутствовать внешний IP, а управляющих серверов было несколько. Я реализовал так, чтобы подключались именно агенты к назначенному серверу (либо резервному, если основной долго отвечает). Держать постоянные соединения было не нужно, агент получал задания по расписанию (по факту 1 раз в минуту оказалось достаточно), при необходимости устанавливалось постоянное соединение (если например нужен был доступ к рабочему столу, тогда по возможности устанавливалось прямое соединение между управляющей консолью и агентом). Всё реализовал на Indy (TIdTCPServer / TIdTCPClient), управляющий сервер выдерживал до 15 тысяч одновременных соединений, для моих целей этого было вполне достаточно. P.S. Вах, сообщения реально редактируются :-) Не мог не отметить этот факт!))))))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.10.2019, 09:18
|
|||
|---|---|---|---|
Реализация сервера в службе |
|||
|
#18+
alekcvp... а человек на консоли, отдав команду сидит и несколько секунд ждёт пока она выполнится?.. Не думаю что это хороший вариант, ничто так не раздражает (меня, например) как "лагающий" без причины интерфейс у приложения. отображаешь окно - "идет установка соединения", и человек не нервничает. Можно с кнопкой "отмена" .Обрати внимание, когда например делаешь видеозвонок через вайбер, или скайп - там тоже всё не мгновенно, тебе точно также пишут, что идет вызов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.10.2019, 09:35
|
|||
|---|---|---|---|
Реализация сервера в службе |
|||
|
#18+
alekcvpТ.к. клиентов дофига, то делать по потоку на каждого тоже не хочется (в пике их может быть до 500500 еще не величина для особых беспокойств. размер стэка только конечно хорошо бы отрегулировать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.10.2019, 10:02
|
|||
|---|---|---|---|
Реализация сервера в службе |
|||
|
#18+
asutp2Держать постоянные соединения было не нужно, агент получал задания по расписанию (по факту 1 раз в минуту оказалось достаточно), при необходимости устанавливалось постоянное соединение (если например нужен был доступ к рабочему столу, тогда по возможности устанавливалось прямое соединение между управляющей консолью и агентом). Это by-design, т.е агентом устанавливает соединение с сервером, выполняются некоторые настройки, после чего запускается длительный процесс (где-то на час). Требуется чтобы оператор видел состояние этого процесса, сколько завершено, где произошёл сбой (для этого и нужно постоянное соединение, т.к. компьютер с агентом может тупо повиснуть), и при необходимости мог отменить процесс. Плюс во время этих операций нагрузка на сеть максимальная и установка новых соединений может вообще отвалиться по таймауту. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.10.2019, 10:38
|
|||
|---|---|---|---|
Реализация сервера в службе |
|||
|
#18+
Можно немного заморочиться и освоить асинхронную коммуникацию с помощью либы ICS. Хотя для новичка она и не особо дружелюбна, но событийная модель та же, что и у VCL. И кстати, рекомендую не изобретать велосипед со своим протоколом и сесть на что-либо стандартное. REST, например. А можно вообще заюзать zeromq (нужна будет dll) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.10.2019, 11:14
|
|||
|---|---|---|---|
Реализация сервера в службе |
|||
|
#18+
alekcvpasutp2Держать постоянные соединения было не нужно, агент получал задания по расписанию (по факту 1 раз в минуту оказалось достаточно), при необходимости устанавливалось постоянное соединение (если например нужен был доступ к рабочему столу, тогда по возможности устанавливалось прямое соединение между управляющей консолью и агентом). Это by-design, т.е агентом устанавливает соединение с сервером, выполняются некоторые настройки, после чего запускается длительный процесс (где-то на час). Требуется чтобы оператор видел состояние этого процесса, сколько завершено, где произошёл сбой (для этого и нужно постоянное соединение, т.к. компьютер с агентом может тупо повиснуть), и при необходимости мог отменить процесс. Плюс во время этих операций нагрузка на сеть максимальная и установка новых соединений может вообще отвалиться по таймауту.так пусть агент при выполнении задачи отправляет инфу о статусе допустим 1 раз в секунду. А при ожидании команды от сервера пусть периодически подключается с бОльшим интервалом (гапример 1 раз в минуту). Постоянные соединения это конечно хорошо, если к серверу подключается небольшое количество агентов. Но если ты рассчитываешь на обслуживание сервером тысяч агентов, то тогда продолжительность соединения агента с сервером должна быть минимизирована. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.10.2019, 13:24
|
|||
|---|---|---|---|
|
|||
Реализация сервера в службе |
|||
|
#18+
alekcvpво время этих операций нагрузка на сеть максимальная и установка новых соединений может вообще отвалиться по таймауту. Это надо сильно постараться чтобы так криво написать сервер. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
31.10.2019, 16:22
|
|||
|---|---|---|---|
Реализация сервера в службе |
|||
|
#18+
Dimitry Sibiryakovalekcvpво время этих операций нагрузка на сеть максимальная и установка новых соединений может вообще отвалиться по таймауту. Это надо сильно постараться чтобы так криво написать сервер. Это передача многогигабайтных файлов по сети через SMB. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=58&tablet=1&tid=2038886]: |
0ms |
get settings: |
8ms |
get forum list: |
8ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
156ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
37ms |
get tp. blocked users: |
1ms |
| others: | 225ms |
| total: | 449ms |
| 0 / 0 |
