Здравствуйте, genre, Вы писали:
G>Здравствуйте, Undying, Вы писали:
G>надоело гадать. либо автор уточнит требования, либо пусть сам выбирает из предложенных вариантов.
Автор сам уже запутался что хочет
Re[12]: [.NET] событийная модель в распределенной системе
Здравствуйте, Aviator, Вы писали:
G>>А че тогда раз в час не спрашивать? Видимо требуется реагировать как-то на каждое изменение. A>А если у вас датчики будут по 100 раз в секунду обновляться будете столько же раз запрашивать состояние и рисовать его на экране? Кому это нужно то? Запрашивайте раз в секунду и все буду счастливы, и юзер и зазакчик и сервер.
Бывает что и нужно. Не обязательно же данные рисуются на экране, бывает они обрабатываются и система как-то реагирует на изменения.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[8]: [.NET] событийная модель в распределенной системе
Здравствуйте, Aviator, Вы писали:
G>>Возможно и не единственное. Но схема когда клиент раз в длительный промежуток времени делает запросы к серверу, а все остальное время ждет асинхронных данных от него, причем с минимальной задержкой, вполне себе валидна. A>Ну и зачем серверу вести набор подключенных клиентов, заботится о мониторинге состояния клиентов, рассылать всем извещения, думать как поступать если извещения не успевает получить клиент и т.д. и т.п.? Ваша валидная схема сразу же приводит к куче проблем, создающих дополнительные сложности и ограничивающие масштабируемость сервера.
ну предложи другую схему. схема с регулярным запросом данных от сервера не работает если нужна минимальная задержка.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[13]: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
G>Здравствуйте, Aviator, Вы писали:
G>>>А че тогда раз в час не спрашивать? Видимо требуется реагировать как-то на каждое изменение. A>>А если у вас датчики будут по 100 раз в секунду обновляться будете столько же раз запрашивать состояние и рисовать его на экране? Кому это нужно то? Запрашивайте раз в секунду и все буду счастливы, и юзер и зазакчик и сервер.
G>Бывает что и нужно. Не обязательно же данные рисуются на экране, бывает они обрабатываются и система как-то реагирует на изменения.
Это вопрос уменьшения периода опроса, если стоит такая задача. Не должно поведение датчика контролировать работу всей системы. Иначе у вас при временном большом количестве изменений всё раком встанет.
Re[9]: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
G>Здравствуйте, Aviator, Вы писали:
G>>>Возможно и не единственное. Но схема когда клиент раз в длительный промежуток времени делает запросы к серверу, а все остальное время ждет асинхронных данных от него, причем с минимальной задержкой, вполне себе валидна. A>>Ну и зачем серверу вести набор подключенных клиентов, заботится о мониторинге состояния клиентов, рассылать всем извещения, думать как поступать если извещения не успевает получить клиент и т.д. и т.п.? Ваша валидная схема сразу же приводит к куче проблем, создающих дополнительные сложности и ограничивающие масштабируемость сервера.
G>ну предложи другую схему. схема с регулярным запросом данных от сервера не работает если нужна минимальная задержка.
Эта минимальная задержка измеряется как-то или просто надо что бы было "всё круто, без задержек"?
Re[9]: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
G>Здравствуйте, Aviator, Вы писали:
G>>>Возможно и не единственное. Но схема когда клиент раз в длительный промежуток времени делает запросы к серверу, а все остальное время ждет асинхронных данных от него, причем с минимальной задержкой, вполне себе валидна. A>>Ну и зачем серверу вести набор подключенных клиентов, заботится о мониторинге состояния клиентов, рассылать всем извещения, думать как поступать если извещения не успевает получить клиент и т.д. и т.п.? Ваша валидная схема сразу же приводит к куче проблем, создающих дополнительные сложности и ограничивающие масштабируемость сервера.
G>ну предложи другую схему. схема с регулярным запросом данных от сервера не работает если нужна минимальная задержка.
Сфоормулируйте точнее требования, выявите кому нужно обрабатывать данные оперативно кому не очень, а кому вообще можно обработать через час (утрированно). Всё зависит от требований, общего решения нет и быть не может, возможно вам придётся выделить высоко приоритетных агентов со специальным интерфейсом взаимодействия. Вообще минимальная задержка, много данных это как-то абстрактно, постарайтесь оперировать конкретными цифрами.
Re[9]: [.NET] событийная модель в распределенной системе
Здравствуйте, cadet354, Вы писали:
G>>Ну и ладно. А спрашивать все равно эффективнее. C>зависит от критичности данных, а то счетчик может несколько раз изменить свое состояние, а клиент этого и не узнает.
Можно запрашивать все изменения за последнюю десятую долю секунды, секунду, минуту, час....
G>>>И если например клиенту нужно знать состояние тысячи из десяти тысяч датчиков, причем с минимальной задержкой, а клиентов сотня, то они просто заддосят сервер. G>>Хреновый сервер если его сотня клиентов с простыми запросами завалят. C>для этих цифр нормальная схема.
Каких цифр какая схема? Я не видел чёткой постановки задачи, может вообще распределённости не требуется
Re[14]: [.NET] событийная модель в распределенной системе
Здравствуйте, Aviator, Вы писали:
G>>Бывает что и нужно. Не обязательно же данные рисуются на экране, бывает они обрабатываются и система как-то реагирует на изменения. A>Это вопрос уменьшения периода опроса, если стоит такая задача. Не должно поведение датчика контролировать работу всей системы. Иначе у вас при временном большом количестве изменений всё раком встанет.
И как его можно уменьшить, если работа системы в том и заключается, чтобы максимально быстро реагировать на изменения?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[10]: [.NET] событийная модель в распределенной системе
Здравствуйте, Aviator, Вы писали:
G>>ну предложи другую схему. схема с регулярным запросом данных от сервера не работает если нужна минимальная задержка. A>Сфоормулируйте точнее требования, выявите кому нужно обрабатывать данные оперативно кому не очень, а кому вообще можно обработать через час (утрированно). Всё зависит от требований, общего решения нет и быть не может, возможно вам придётся выделить высоко приоритетных агентов со специальным интерфейсом взаимодействия. Вообще минимальная задержка, много данных это как-то абстрактно, постарайтесь оперировать конкретными цифрами.
Ну вообще это конечно вопрос не ко мне, но если уж мы обсуждаем предложенный мной вариант:
1. количество клиентов 1-1000 с потенциальным ростом в будущем.
2. все должны получать данные так быстро как это возможно.
3. данных бывает от 1 события в час до 10 в секунду.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[15]: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
G>Здравствуйте, Aviator, Вы писали:
G>>>Бывает что и нужно. Не обязательно же данные рисуются на экране, бывает они обрабатываются и система как-то реагирует на изменения. A>>Это вопрос уменьшения периода опроса, если стоит такая задача. Не должно поведение датчика контролировать работу всей системы. Иначе у вас при временном большом количестве изменений всё раком встанет.
G>И как его можно уменьшить, если работа системы в том и заключается, чтобы максимально быстро реагировать на изменения?
Что значит максимально быстро, 1сек, 100 мс, 10мс задержки? Без задержки не бывает никогда, даже в реалтайм системах. Вопрос поиска компромисса, какое время обработки считается приемлемым и допустимо.
Re[11]: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
G>Здравствуйте, Aviator, Вы писали:
G>>>ну предложи другую схему. схема с регулярным запросом данных от сервера не работает если нужна минимальная задержка. A>>Сфоормулируйте точнее требования, выявите кому нужно обрабатывать данные оперативно кому не очень, а кому вообще можно обработать через час (утрированно). Всё зависит от требований, общего решения нет и быть не может, возможно вам придётся выделить высоко приоритетных агентов со специальным интерфейсом взаимодействия. Вообще минимальная задержка, много данных это как-то абстрактно, постарайтесь оперировать конкретными цифрами.
G>Ну вообще это конечно вопрос не ко мне, но если уж мы обсуждаем предложенный мной вариант: G>1. количество клиентов 1-1000 с потенциальным ростом в будущем. G>2. все должны получать данные так быстро как это возможно.
Опять двадцать пять, какое время на обработку сигнала допустимо? Ставя вопрос по другому, согласен ли заказчик платить за покупку кластера для задержки в 10мс или согласен на задержку в 1сек на текущем железе? G>3. данных бывает от 1 события в час до 10 в секунду.
Если требовать работы системы в реалтайме, то на обработку сигнала есть не более 100мс. Если такие жёсткие требования действительно имеют место быть, а не являются желанием автора сделать универсальное решение, то придётся писать на сокетах. Клиенты соединяются с сервером, сервер складывает события в очередь на отправку, специальный агент отправляет события по мере поступления в очередь подключенным клиентам, клиенты обрабатывают интересующие события. Если допустимы потери событий, то не лишним будет использование udp multicast. Ну и конечно же отслеживание отвала клиента.
Re[16]: [.NET] событийная модель в распределенной системе
Здравствуйте, Aviator, Вы писали:
A>Что значит максимально быстро, 1сек, 100 мс, 10мс задержки? Без задержки не бывает никогда, даже в реалтайм системах. Вопрос поиска компромисса, какое время обработки считается приемлемым и допустимо.
Пусть 100мс.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[12]: [.NET] событийная модель в распределенной системе
Здравствуйте, Aviator, Вы писали:
G>>3. данных бывает от 1 события в час до 10 в секунду. A>Если требовать работы системы в реалтайме, то на обработку сигнала есть не более 100мс. Если такие жёсткие требования действительно имеют место быть, а не являются желанием автора сделать универсальное решение, то придётся писать на сокетах. Клиенты соединяются с сервером, сервер складывает события в очередь на отправку, специальный агент отправляет события по мере поступления в очередь подключенным клиентам, клиенты обрабатывают интересующие события. Если допустимы потери событий, то не лишним будет использование udp multicast. Ну и конечно же отслеживание отвала клиента.
О чем я и говорил.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[13]: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
G>Здравствуйте, Aviator, Вы писали:
G>>>3. данных бывает от 1 события в час до 10 в секунду. A>>Если требовать работы системы в реалтайме, то на обработку сигнала есть не более 100мс. Если такие жёсткие требования действительно имеют место быть, а не являются желанием автора сделать универсальное решение, то придётся писать на сокетах. Клиенты соединяются с сервером, сервер складывает события в очередь на отправку, специальный агент отправляет события по мере поступления в очередь подключенным клиентам, клиенты обрабатывают интересующие события. Если допустимы потери событий, то не лишним будет использование udp multicast. Ну и конечно же отслеживание отвала клиента.
G>О чем я и говорил.
У меня есть сомнения в необходимости обеспечивать эти 100мс. Зачем на 1000 клиентских машинах такая скорость реакции?
Re[14]: [.NET] событийная модель в распределенной системе
Здравствуйте, Aviator, Вы писали:
G>>О чем я и говорил. A>У меня есть сомнения в необходимости обеспечивать эти 100мс. Зачем на 1000 клиентских машинах такая скорость реакции?
Блин. Ну сколько можно пережевывать? Хочется возразить, просто чтобы возразить?
Да, если задача не требует такой реакции то решение может быть другое.
Если требует — то такое.
Или ты хочешь поспорить с тем, что такие задачи бывают?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[15]: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
G>Здравствуйте, Aviator, Вы писали:
G>>>О чем я и говорил. A>>У меня есть сомнения в необходимости обеспечивать эти 100мс. Зачем на 1000 клиентских машинах такая скорость реакции?
G>Блин. Ну сколько можно пережевывать? Хочется возразить, просто чтобы возразить? G>Да, если задача не требует такой реакции то решение может быть другое. G>Если требует — то такое.
Хотел обсудить конкретную задачу топикастера, а не какие задачи бывают. Был наивен.
G>Или ты хочешь поспорить с тем, что такие задачи бывают?
Не хочу
Re[16]: [.NET] событийная модель в распределенной системе
Здравствуйте, Aviator, Вы писали:
A>Хотел обсудить конкретную задачу топикастера, а не какие задачи бывают. Был наивен.
Извини, грубовато вышло. Просто уже на третий круг пошло. Топикстартер задал очень общие условия, ему предложили несколько вариантов решения задачи в зависимости от того какие у него на самом деле требования.
После чего к каждому варианту появился коммент "а если у топикстартера не так". Ну а если не так — вот рядом другой вариант решения задачи предложили, в нужных начальных условиях.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[10]: [.NET] событийная модель в распределенной системе
Здравствуйте, Aviator, Вы писали:
A>Каких цифр какая схема? Я не видел чёткой постановки задачи, может вообще распределённости не требуется
ТС пишет:
Есть сервер который постоянно получает входные данные и их обрабатывает, и есть GUI клиенты (WPF), которые должны получать
информацию от сервера (в основном клиенты занимаються мониторингом).
Максимальное количество таких событий 5-10 в секунду.
что тут в условиях не понятно
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re[11]: [.NET] событийная модель в распределенной системе
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, Aviator, Вы писали:
A>>Каких цифр какая схема? Я не видел чёткой постановки задачи, может вообще распределённости не требуется C>ТС пишет:
C>
C>Есть сервер который постоянно получает входные данные и их обрабатывает, и есть GUI клиенты (WPF), которые должны получать
C>информацию от сервера (в основном клиенты занимаються мониторингом).
C>
C>Максимальное количество таких событий 5-10 в секунду.
C>что тут в условиях не понятно
Где в этих условиях указана время реакции клиента на события с сервера?
Re[12]: [.NET] событийная модель в распределенной системе
