|
Клиент-серверное приложение для SNMP-датчиков
|
|||
---|---|---|---|
#18+
Здравствуйте, форумчане, Ситуация такая. Есть множество датчиков, скажем, температурных. Их около 150. Они все подключены к сети, т.к. у них есть Ethernet-адаптер. я написал программу (C# WinForms), которая в таблице выводит их значения типа: Датчик №1 -- +15° Датчик №2 -- +27° и т.п. Датчики периодически опрашиваются по SNMP. Более того, они сами иногда отправляют SNMP-сообщения, если температура превысила некий лимит. Теперь смотрите. Это хорошо работает, если такая программа в сети одна. Но сейчас нужно, чтобы их было, скажем, 30. То есть, нужна клиент-серверная версия. Сервер будет опрашивать все датчики и будет как бы в курсе всего, а клиенты будут подключаться к серверу и спрашивать уже у него. Возникли вопросы: 1) правильно ли я понимаю, что сервер по-хорошему должен быть Windows-службой? 2) как клиентам получать информацию с сервера? По SNMP? Обращаться к какому-то shared хранилищу? Или лучше, чтобы это была web-служба? 3) если датчик отправил серверу тревожное сообщение о превышении температуры, как серверу переслать его всем клиентам? Это какой-то multicast должен быть или что?? Или по очереди всем отправлять? Буду благодарен также за любые абстрактные советы или ссылки о том, как правильно писать клиент-серверные приложения и какие могут быть нюансы. я запостил это в общий раздел, а не в Microsoft.NET, т.к. мне интересно, как это правильно сделать с общих позиций, реализация конкретного языка это второй вопрос... ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2014, 18:38 |
|
Клиент-серверное приложение для SNMP-датчиков
|
|||
---|---|---|---|
#18+
Капюшон, Субд напр. Оракл. Там есть job задания. Напр. Раз в мин. Опросить все датчики. Тогда клиент к субд напишет любой студент. ... |
|||
:
Нравится:
Не нравится:
|
|||
14.02.2014, 19:11 |
|
Клиент-серверное приложение для SNMP-датчиков
|
|||
---|---|---|---|
#18+
Всем привет еще раз! Поднимаю эту тему, т.к. сейчас она стала действительно актуальной :–) У меня нет опыта в построении клиент-серверных сетевых приложений, поэтому нужна помощь. СУБД в качестве сервера здесь как мне кажется не подходит... т.к. это совершенно иное ПО. У меня есть такая идея: 1) сервер периодически опрашивает датчики по SNMP (с этим всё понятно) 2) сервер ведет актуальный список подключившихся клиентов и держит с ними TCP-сессии 3) когда происходит некое событие от датчика, сервер переправляет соответствующую информацию всем подключившимся клиентам. Просьба прокомментировать. Можно ли вместо TCP-подключения использовать что-либо более легковесное? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2015, 15:20 |
|
Клиент-серверное приложение для SNMP-датчиков
|
|||
---|---|---|---|
#18+
UDP :) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2015, 15:31 |
|
Клиент-серверное приложение для SNMP-датчиков
|
|||
---|---|---|---|
#18+
КапюшонВсем привет еще раз! Поднимаю эту тему, т.к. сейчас она стала действительно актуальной :–) У меня нет опыта в построении клиент-серверных сетевых приложений, поэтому нужна помощь. СУБД в качестве сервера здесь как мне кажется не подходит... т.к. это совершенно иное ПО. У меня есть такая идея: 1) сервер периодически опрашивает датчики по SNMP (с этим всё понятно) 2) сервер ведет актуальный список подключившихся клиентов и держит с ними TCP-сессии 3) когда происходит некое событие от датчика, сервер переправляет соответствующую информацию всем подключившимся клиентам. Просьба прокомментировать. Можно ли вместо TCP-подключения использовать что-либо более легковесное? 1.да 2.да, но не обязательно. 3.нет. сервер потому так и зовется, что только отвечает на вопросы (исключения бывают, но ничего хорошего в них нет). когда клиенту нужна информация, он шлет запрос серверу и тот отвечает. если в секунду будет менее 1000 запросов, то нет смысла искать что-то легковеснее tcp. в противном случае надо думать. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.02.2015, 23:10 |
|
Клиент-серверное приложение для SNMP-датчиков
|
|||
---|---|---|---|
#18+
С одной стороны, сервер действительно должен только отвечать на запросы, однако, как быть в том случае, когда SNMP-датчик отправляет на сервер тревожное сообщение, о котором должны быть извещены все клиенты? ... |
|||
:
Нравится:
Не нравится:
|
|||
27.02.2015, 16:11 |
|
Клиент-серверное приложение для SNMP-датчиков
|
|||
---|---|---|---|
#18+
Значит все клиенты должны быть постоянно подключены к серверу и постоянно ожидать от него прихода сообщения. Это очень легко программируется. ... |
|||
:
Нравится:
Не нравится:
|
|||
28.02.2015, 15:05 |
|
Клиент-серверное приложение для SNMP-датчиков
|
|||
---|---|---|---|
#18+
Но как именно клиенты должны быть подключены к серверу? Допускаю, вопрос может быть глупый, но я на самом деле не знаю, как это сделать правильно, максимально просто и легковесно. (Пишу на C# если что.) Мне в голову приходит только TCP/UDP-подключение (т.е. TCP Listener и т.п.) Нужно правильно выбрать способ подключения, т.к. это будет основой новой клиент-серверной системы. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2015, 13:01 |
|
Клиент-серверное приложение для SNMP-датчиков
|
|||
---|---|---|---|
#18+
Слушай, а нет в природе snmp-opc шлюза? точно есть opc-веб-сервис шлюз. так можно было бы обойтись без велосипедства, а воспользовавшись промышленными протоколами. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2015, 13:18 |
|
Клиент-серверное приложение для SNMP-датчиков
|
|||
---|---|---|---|
#18+
КапюшонНо как именно клиенты должны быть подключены к серверу? Лично я бы выбрал TCP. Но можно и Named Pipes, Mailslots и т.д. и т.п. КапюшонДопускаю, вопрос может быть глупый, но я на самом деле не знаю, как это сделать правильно, максимально просто и легковесно. (Пишу на C# если что.) Перейди на простой Си и это будет просто и легковесно: отдельный поток, в нём recv() и что-нибудь для сигнализации главному потоку о приходе сообщения. ... |
|||
:
Нравится:
Не нравится:
|
|||
04.03.2015, 15:02 |
|
|
start [/forum/topic.php?fid=33&fpage=12&tid=1547501]: |
0ms |
get settings: |
9ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
48ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
others: | 330ms |
total: | 472ms |
0 / 0 |