Разрабатываеться распределенная система.
Есть сервер который постоянно получает входные данные и их обрабатывает, и есть GUI клиенты (WPF), которые должны получать
информацию от сервера (в основном клиенты занимаються мониторингом).
Задача состоит в том, что клиенты не должны получать всю информацию, которыми в данный момент распологает сервер, а должны
получать только данные в зависимости от текущего пользовательского экрана + прав доступа пользователя.
Возникла идея событийной модели: пользователь попадает на экран — клиент подписываеться на какое-то
серверное событие, при возникновении которого сервер посылает клиенту данные и тот их отображает. При переходе на другой экран
клиент отписываеться от текущего события и подписывается на другое. Максимальное количество таких событий 5-10 в секунду.
Вопрос в том как это реализовать наименее геморойно в стеке технологий .NET? Или возможно эта идея бредовая?
Буду благодарен любым мыслям, советам, ссылкам! Я впервые столкнулся с распределенными приложениям
... << RSDN@Home 1.2.0 alpha 4 rev. 1445>>
Re: [.NET] событийная модель в распределенной системе
Здравствуйте, xk, Вы писали:
xk>Задача состоит в том, что клиенты не должны получать всю информацию, которыми в данный момент распологает сервер, а должны xk>получать только данные в зависимости от текущего пользовательского экрана + прав доступа пользователя.
xk>Возникла идея событийной модели: пользователь попадает на экран — клиент подписываеться на какое-то xk>серверное событие, при возникновении которого сервер посылает клиенту данные и тот их отображает. При переходе на другой экран xk>клиент отписываеться от текущего события и подписывается на другое. Максимальное количество таких событий 5-10 в секунду.
xk>Вопрос в том как это реализовать наименее геморойно в стеке технологий .NET? Или возможно эта идея бредовая?
Конечно бредовая. Клиент сам должен запрашивать все что ему надо, а сервер должен отдавать что доступно клиенту. Не надо никаких событий.
xk> Я впервые столкнулся с распределенными приложениям
Заметно.
Re[2]: [.NET] событийная модель в распределенной системе
Здравствуйте, gandjustas, Вы писали:
xk>>Задача состоит в том, что клиенты не должны получать всю информацию, которыми в данный момент распологает сервер, а должны xk>>получать только данные в зависимости от текущего пользовательского экрана + прав доступа пользователя.
xk>>Возникла идея событийной модели: пользователь попадает на экран — клиент подписываеться на какое-то xk>>серверное событие, при возникновении которого сервер посылает клиенту данные и тот их отображает. При переходе на другой экран xk>>клиент отписываеться от текущего события и подписывается на другое. Максимальное количество таких событий 5-10 в секунду.
G>Конечно бредовая. Клиент сам должен запрашивать все что ему надо, а сервер должен отдавать что доступно клиенту. Не надо никаких событий.
Ну если например клиент должен получать данные асинхронно, то не такая уж и бредовая. Иначе как реализовать запросы вида "а сообщи мне когда температура на датчике 143634 измениться"?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[3]: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
xk>>>Задача состоит в том, что клиенты не должны получать всю информацию, которыми в данный момент распологает сервер, а должны xk>>>получать только данные в зависимости от текущего пользовательского экрана + прав доступа пользователя.
xk>>>Возникла идея событийной модели: пользователь попадает на экран — клиент подписываеться на какое-то xk>>>серверное событие, при возникновении которого сервер посылает клиенту данные и тот их отображает. При переходе на другой экран xk>>>клиент отписываеться от текущего события и подписывается на другое. Максимальное количество таких событий 5-10 в секунду.
G>>Конечно бредовая. Клиент сам должен запрашивать все что ему надо, а сервер должен отдавать что доступно клиенту. Не надо никаких событий.
G>Ну если например клиент должен получать данные асинхронно, то не такая уж и бредовая.
Все равно бредовая
G>Иначе как реализовать запросы вида "а сообщи мне когда температура на датчике 143634 измениться"?
polling
Чтобы сервер что-то сообщал клиенту по своему усмотрению надо держать открытым соединение. Это дорого, это ломает любые схемы failover, это приводт к тому что сервер вынужден у себя хранить состояние клиента для многих сценариев работы. Кроме того у сервера мало возможностей отслеживать жив ли вообще клиент или нет, это плохо влияет на API.
Re: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
G>>>Иначе как реализовать запросы вида "а сообщи мне когда температура на датчике 143634 измениться"? G>>polling
G>ну то есть ты предлагаешь постоянно опрашивать сервер о состоянии этого конкретного датчика?
Я не думаю что это единственное о чем будет спрашивать клиент.
Re[6]: [.NET] событийная модель в распределенной системе
Здравствуйте, gandjustas, Вы писали:
G>>>>Иначе как реализовать запросы вида "а сообщи мне когда температура на датчике 143634 измениться"? G>>>polling
G>>ну то есть ты предлагаешь постоянно опрашивать сервер о состоянии этого конкретного датчика? G>Я не думаю что это единственное о чем будет спрашивать клиент.
Возможно и не единственное. Но схема когда клиент раз в длительный промежуток времени делает запросы к серверу, а все остальное время ждет асинхронных данных от него, причем с минимальной задержкой, вполне себе валидна.
И если например клиенту нужно знать состояние тысячи из десяти тысяч датчиков, причем с минимальной задержкой, а клиентов сотня, то они просто заддосят сервер.
А схема с подпиской будет отлично работать.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[7]: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
G>>>>>Иначе как реализовать запросы вида "а сообщи мне когда температура на датчике 143634 измениться"? G>>>>polling
G>>>ну то есть ты предлагаешь постоянно опрашивать сервер о состоянии этого конкретного датчика? G>>Я не думаю что это единственное о чем будет спрашивать клиент.
G>Возможно и не единственное. Но схема когда клиент раз в длительный промежуток времени делает запросы к серверу, а все остальное время ждет асинхронных данных от него, причем с минимальной задержкой, вполне себе валидна.
Ну и ладно. А спрашивать все равно эффективнее.
G>И если например клиенту нужно знать состояние тысячи из десяти тысяч датчиков, причем с минимальной задержкой, а клиентов сотня, то они просто заддосят сервер.
Хреновый сервер если его сотня клиентов с простыми запросами завалят.
G>А схема с подпиской будет отлично работать.
Ну напиши такой сервер, посмотрим.
Re[8]: [.NET] событийная модель в распределенной системе
Здравствуйте, gandjustas, Вы писали:
G>>И если например клиенту нужно знать состояние тысячи из десяти тысяч датчиков, причем с минимальной задержкой, а клиентов сотня, то они просто заддосят сервер. G>Хреновый сервер если его сотня клиентов с простыми запросами завалят.
Быстр ты ярлыки вешать. Кто сказал, что запросы простые? Сервер на каждый запрос должен сделать выборку по доступным датчикам, проверить права доступа, итд.
G>>А схема с подпиской будет отлично работать. G>Ну напиши такой сервер, посмотрим.
Ну сервера раздающие финансовую инфу, котировки например, именно так и работают.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[9]: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
G>>>И если например клиенту нужно знать состояние тысячи из десяти тысяч датчиков, причем с минимальной задержкой, а клиентов сотня, то они просто заддосят сервер. G>>Хреновый сервер если его сотня клиентов с простыми запросами завалят.
G>Быстр ты ярлыки вешать. Кто сказал, что запросы простые? Сервер на каждый запрос должен сделать выборку по доступным датчикам, проверить права доступа, итд.
В большинстве случаев сервер скажет что ничего не изменилось.
Если что-то изменилось, то скажет когда изменилось последний раз и вышлет изменения из своего кеша.
Если данных в кеше нет, то вытащит их из хранилища.
Сервер по такому же принципу работает с БД. Получает изменения с даты последнего считывания и сохраняет в кеше.
G>>>А схема с подпиской будет отлично работать. G>>Ну напиши такой сервер, посмотрим.
G>Ну сервера раздающие финансовую инфу, котировки например, именно так и работают.
Ну ты же не сервер, раздающий финансовую инфу пишешь.
Там важна скорость, передачи. Чем быстрее, тем лучше. А для отображения температуры этого не надо.
Re[8]: [.NET] событийная модель в распределенной системе
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, genre, Вы писали:
G>>Здравствуйте, gandjustas, Вы писали:
G>>>>>>Иначе как реализовать запросы вида "а сообщи мне когда температура на датчике 143634 измениться"? G>>>>>polling
G>>>>ну то есть ты предлагаешь постоянно опрашивать сервер о состоянии этого конкретного датчика? G>>>Я не думаю что это единственное о чем будет спрашивать клиент.
G>>Возможно и не единственное. Но схема когда клиент раз в длительный промежуток времени делает запросы к серверу, а все остальное время ждет асинхронных данных от него, причем с минимальной задержкой, вполне себе валидна. G>Ну и ладно. А спрашивать все равно эффективнее.
зависит от критичности данных, а то счетчик может несколько раз изменить свое состояние, а клиент этого и не узнает.
G>>И если например клиенту нужно знать состояние тысячи из десяти тысяч датчиков, причем с минимальной задержкой, а клиентов сотня, то они просто заддосят сервер. G>Хреновый сервер если его сотня клиентов с простыми запросами завалят.
для этих цифр нормальная схема.
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re: [.NET] событийная модель в распределенной системе
Здравствуйте, xk, Вы писали:
xk>Здравствуйте.
xk>Разрабатываеться распределенная система. xk>Есть сервер который постоянно получает входные данные и их обрабатывает, и есть GUI клиенты (WPF), которые должны получать xk>информацию от сервера (в основном клиенты занимаються мониторингом).
xk>Задача состоит в том, что клиенты не должны получать всю информацию, которыми в данный момент распологает сервер, а должны xk>получать только данные в зависимости от текущего пользовательского экрана + прав доступа пользователя.
xk>Возникла идея событийной модели: пользователь попадает на экран — клиент подписываеться на какое-то xk>серверное событие, при возникновении которого сервер посылает клиенту данные и тот их отображает. При переходе на другой экран xk>клиент отписываеться от текущего события и подписывается на другое. Максимальное количество таких событий 5-10 в секунду.
xk>Вопрос в том как это реализовать наименее геморойно в стеке технологий .NET? Или возможно эта идея бредовая?
можно еще глянуть в сторону event system например rabbitmq есть клиент для .net
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re[10]: [.NET] событийная модель в распределенной системе
Здравствуйте, gandjustas, Вы писали:
G>В большинстве случаев сервер скажет что ничего не изменилось. G>Если что-то изменилось, то скажет когда изменилось последний раз и вышлет изменения из своего кеша. G>Если данных в кеше нет, то вытащит их из хранилища.
Что ничего не изменилось по каждому датчику тоже надо проверять. А при большом количестве клиентов и датчиков это все может оказаться не быстро. А главное — зачем это делать, если можно не делать?
G>>Ну сервера раздающие финансовую инфу, котировки например, именно так и работают. G>Ну ты же не сервер, раздающий финансовую инфу пишешь. G>Там важна скорость, передачи. Чем быстрее, тем лучше. А для отображения температуры этого не надо.
Ну мы не знаем что конкретно пишет автор топика.
Мое дело маленькое, ситуацию, когда то что он предлагает не бред я тебе предложил.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re: [.NET] событийная модель в распределенной системе
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, genre, Вы писали:
G>>>Здравствуйте, gandjustas, Вы писали:
G>>>>>>>Иначе как реализовать запросы вида "а сообщи мне когда температура на датчике 143634 измениться"? G>>>>>>polling
G>>>>>ну то есть ты предлагаешь постоянно опрашивать сервер о состоянии этого конкретного датчика? G>>>>Я не думаю что это единственное о чем будет спрашивать клиент.
G>>>Возможно и не единственное. Но схема когда клиент раз в длительный промежуток времени делает запросы к серверу, а все остальное время ждет асинхронных данных от него, причем с минимальной задержкой, вполне себе валидна. G>>Ну и ладно. А спрашивать все равно эффективнее. C>зависит от критичности данных, а то счетчик может несколько раз изменить свое состояние, а клиент этого и не узнает.
Если датчик температуры за секунду 500 раз поменяет значение сколько изменений увидит пользователь?
Re[11]: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
G>>В большинстве случаев сервер скажет что ничего не изменилось. G>>Если что-то изменилось, то скажет когда изменилось последний раз и вышлет изменения из своего кеша. G>>Если данных в кеше нет, то вытащит их из хранилища.
G>Что ничего не изменилось по каждому датчику тоже надо проверять. А при большом количестве клиентов и датчиков это все может оказаться не быстро. А главное — зачем это делать, если можно не делать?
Вот я тоже не понял, зачем проверять если можно не проверять.
G>>>Ну сервера раздающие финансовую инфу, котировки например, именно так и работают. G>>Ну ты же не сервер, раздающий финансовую инфу пишешь. G>>Там важна скорость, передачи. Чем быстрее, тем лучше. А для отображения температуры этого не надо.
G>Ну мы не знаем что конкретно пишет автор топика.
Если бы он писал сервер торговой системы, то он бы вряд ли тут вопросы задавал.
Re[12]: [.NET] событийная модель в распределенной системе
Здравствуйте, gandjustas, Вы писали:
G>>Ну мы не знаем что конкретно пишет автор топика. G>Если бы он писал сервер торговой системы, то он бы вряд ли тут вопросы задавал.
Ну наше дело не гадать, а указать все возможные варианты.
Ты с тем, что подписки не всегда бред уже согласен?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[13]: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
G>>>Ну мы не знаем что конкретно пишет автор топика. G>>Если бы он писал сервер торговой системы, то он бы вряд ли тут вопросы задавал.
G>Ну наше дело не гадать, а указать все возможные варианты.
G>Ты с тем, что подписки не всегда бред уже согласен?
Не-а. Можно продолжить. Кроме архитектурных проблем с подписками, есть и те, которые появятся при реализации через события.
Например отслеживание время жизни объекта, к которому подписываются и тому подобное.
Поэтому подписками не стоит заниматься, только в том случае когда надо будет с минимальной латентностью передавать данные от сервера.
Re[10]: [.NET] событийная модель в распределенной системе
Здравствуйте, gandjustas, Вы писали:
C>>зависит от критичности данных, а то счетчик может несколько раз изменить свое состояние, а клиент этого и не узнает. G>Если датчик температуры за секунду 500 раз поменяет значение сколько изменений увидит пользователь?
мы тут не сферического коня рассматриваем, ТС пишет:
Максимальное количество таких событий 5-10 в секунду.
Re[4]: [.NET] событийная модель в распределенной системе
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, genre, Вы писали:
G>>Здравствуйте, gandjustas, Вы писали:
xk>>>>Задача состоит в том, что клиенты не должны получать всю информацию, которыми в данный момент распологает сервер, а должны xk>>>>получать только данные в зависимости от текущего пользовательского экрана + прав доступа пользователя.
xk>>>>Возникла идея событийной модели: пользователь попадает на экран — клиент подписываеться на какое-то xk>>>>серверное событие, при возникновении которого сервер посылает клиенту данные и тот их отображает. При переходе на другой экран xk>>>>клиент отписываеться от текущего события и подписывается на другое. Максимальное количество таких событий 5-10 в секунду.
G>>>Конечно бредовая. Клиент сам должен запрашивать все что ему надо, а сервер должен отдавать что доступно клиенту. Не надо никаких событий.
G>>Ну если например клиент должен получать данные асинхронно, то не такая уж и бредовая. G>Все равно бредовая
G>>Иначе как реализовать запросы вида "а сообщи мне когда температура на датчике 143634 измениться"? G>polling
G>Чтобы сервер что-то сообщал клиенту по своему усмотрению надо держать открытым соединение. Это дорого, это ломает любые схемы failover, это приводт к тому что сервер вынужден у себя хранить состояние клиента для многих сценариев работы. Кроме того у сервера мало возможностей отслеживать жив ли вообще клиент или нет, это плохо влияет на API.
Здравствуйте, LeonidV, Вы писали:
LV>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, genre, Вы писали:
G>>>Здравствуйте, gandjustas, Вы писали:
xk>>>>>Задача состоит в том, что клиенты не должны получать всю информацию, которыми в данный момент распологает сервер, а должны xk>>>>>получать только данные в зависимости от текущего пользовательского экрана + прав доступа пользователя.
xk>>>>>Возникла идея событийной модели: пользователь попадает на экран — клиент подписываеться на какое-то xk>>>>>серверное событие, при возникновении которого сервер посылает клиенту данные и тот их отображает. При переходе на другой экран xk>>>>>клиент отписываеться от текущего события и подписывается на другое. Максимальное количество таких событий 5-10 в секунду.
G>>>>Конечно бредовая. Клиент сам должен запрашивать все что ему надо, а сервер должен отдавать что доступно клиенту. Не надо никаких событий.
G>>>Ну если например клиент должен получать данные асинхронно, то не такая уж и бредовая. G>>Все равно бредовая
G>>>Иначе как реализовать запросы вида "а сообщи мне когда температура на датчике 143634 измениться"? G>>polling
G>>Чтобы сервер что-то сообщал клиенту по своему усмотрению надо держать открытым соединение. Это дорого, это ломает любые схемы failover, это приводт к тому что сервер вынужден у себя хранить состояние клиента для многих сценариев работы. Кроме того у сервера мало возможностей отслеживать жив ли вообще клиент или нет, это плохо влияет на API.
LV>Я только одно слово напишу — websockets.
Еще напиши где оно работает.
Re[6]: [.NET] событийная модель в распределенной системе
Здравствуйте, gandjustas, Вы писали:
LV>>Я только одно слово напишу — websockets.
G>Еще напиши где оно работает.
Есть реализации серверов и клиентов для Java.
Здравствуйте, gandjustas, Вы писали:
G>Еще напиши где оно работает.
Суть не в том, где оно работает сейчас или нет. Суть в том что:
а). Не нужен весьма не эффективный механизм polling'а;
b). websockets сервера держат десятки тысяч одновременных подключений;
Здравствуйте, gandjustas, Вы писали:
G>Не-а. Можно продолжить.
Ну тогда надо уточнить требования.
G>Кроме архитектурных проблем с подписками, есть и те, которые появятся при реализации через события. G>Например отслеживание время жизни объекта, к которому подписываются и тому подобное.
Подробнее?
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[15]: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
G>>Кроме архитектурных проблем с подписками, есть и те, которые появятся при реализации через события. G>>Например отслеживание время жизни объекта, к которому подписываются и тому подобное.
G>Подробнее?
Смотри архитектуру .NET Remoting.
Re[16]: [.NET] событийная модель в распределенной системе
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, genre, Вы писали:
G>>>Кроме архитектурных проблем с подписками, есть и те, которые появятся при реализации через события. G>>>Например отслеживание время жизни объекта, к которому подписываются и тому подобное.
G>>Подробнее?
G>Смотри архитектуру .NET Remoting.
мы обсуждаем архитектуру .Net Remoting или общие проблемы архитектуры подобных систем? Если первое, то я пас.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[17]: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, genre, Вы писали:
G>>>>Кроме архитектурных проблем с подписками, есть и те, которые появятся при реализации через события. G>>>>Например отслеживание время жизни объекта, к которому подписываются и тому подобное.
G>>>Подробнее?
G>>Смотри архитектуру .NET Remoting.
G>мы обсуждаем архитектуру .Net Remoting или общие проблемы архитектуры подобных систем? Если первое, то я пас.
Если хочется подписываться на события, но получится нечто похожее.
Re[18]: [.NET] событийная модель в распределенной системе
Здравствуйте, gandjustas, Вы писали:
G>>>>>Кроме архитектурных проблем с подписками, есть и те, которые появятся при реализации через события. G>>>>>Например отслеживание время жизни объекта, к которому подписываются и тому подобное.
G>>>>Подробнее?
G>>>Смотри архитектуру .NET Remoting.
G>>мы обсуждаем архитектуру .Net Remoting или общие проблемы архитектуры подобных систем? Если первое, то я пас.
G>Если хочется подписываться на события, но получится нечто похожее.
Чего вдруг? В обсуждавшемся выше варианте с температурными датчиками никаких объектов может вообще не быть, то есть и время жизни отслеживать не надо
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[7]: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
G>И если например клиенту нужно знать состояние тысячи из десяти тысяч датчиков, причем с минимальной задержкой, а клиентов сотня, то они просто заддосят сервер.
Задосят, если клиент будет для каждого датчика отдельный запрос слать. А если он, скажем, раз в секунду будет получать все изменения состояния всех датчиков за прошедшую секунду, то проблем никаких не будет.
Re[8]: [.NET] событийная модель в распределенной системе
Здравствуйте, Undying, Вы писали:
U>Задосят, если клиент будет для каждого датчика отдельный запрос слать. А если он, скажем, раз в секунду будет получать все изменения состояния всех датчиков за прошедшую секунду, то проблем никаких не будет.
ну там 5-10 раз в секунду меняются датчики
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[9]: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
U>>Задосят, если клиент будет для каждого датчика отдельный запрос слать. А если он, скажем, раз в секунду будет получать все изменения состояния всех датчиков за прошедшую секунду, то проблем никаких не будет.
G>ну там 5-10 раз в секунду меняются датчики
В этом случае по каждому датчику будет возвращаться по 5-10 состояний с временем когда произошло переключение для каждого из них, в чем проблема-то?
Re[10]: [.NET] событийная модель в распределенной системе
Здравствуйте, Undying, Вы писали:
U>В этом случае по каждому датчику будет возвращаться по 5-10 состояний с временем когда произошло переключение для каждого из них, в чем проблема-то?
А че тогда раз в час не спрашивать? Видимо требуется реагировать как-то на каждое изменение.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[11]: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
U>>В этом случае по каждому датчику будет возвращаться по 5-10 состояний с временем когда произошло переключение для каждого из них, в чем проблема-то? G>А че тогда раз в час не спрашивать? Видимо требуется реагировать как-то на каждое изменение.
А кто здесь мешает реагировать на каждое изменение? Тут минус только один, клиент получает информацию об изменении через секунду после того как оно произошло. Если реагировать на изменение должен человек, то такая скорость реакции более чем достаточна. Если же автоматика и по условию задачи важны даже доли секунды, тогда да альтернативы подписке нет.
Re[12]: [.NET] событийная модель в распределенной системе
Здравствуйте, Undying, Вы писали:
U>А кто здесь мешает реагировать на каждое изменение? Тут минус только один, клиент получает информацию об изменении через секунду после того как оно произошло. Если реагировать на изменение должен человек, то такая скорость реакции более чем достаточна. Если же автоматика и по условию задачи важны даже доли секунды, тогда да альтернативы подписке нет.
о чём и речь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>
Re[13]: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
U>>А кто здесь мешает реагировать на каждое изменение? Тут минус только один, клиент получает информацию об изменении через секунду после того как оно произошло. Если реагировать на изменение должен человек, то такая скорость реакции более чем достаточна. Если же автоматика и по условию задачи важны даже доли секунды, тогда да альтернативы подписке нет.
G>о чём и речь.
Автор темы пишет:
Задача состоит в том, что клиенты не должны получать всю информацию, которыми в данный момент распологает сервер, а должны
получать только данные в зависимости от текущего пользовательского экрана + прав доступа пользователя.
Т.е. данные явно предназначаются для человека. Для человека скорости реакции системы в 1 с более чем достаточно, соответственно особого смысла использовать подписку нет.
Re[14]: [.NET] событийная модель в распределенной системе
Здравствуйте, LeonidV, Вы писали:
LV>Я только одно слово напишу — websockets.
А я признаться, не понял, при чём тут websockets Разве автор говорил, что ему нужно соединяться по HTTP? Если речь о работе через WEB, то, имхо, о lдетерменированном времени обновления данных надо забыть — ответ от сервера может дойти и за пол-секунды, и 10 секунд может ползти. А если всё хозяйство в локальной сети, то зачем websockets, а не просто TCP (если не UDP)?
"Нормальные герои всегда идут в обход!"
Re[7]: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
G>Здравствуйте, gandjustas, Вы писали:
G>>>>>Иначе как реализовать запросы вида "а сообщи мне когда температура на датчике 143634 измениться"? G>>>>polling
G>>>ну то есть ты предлагаешь постоянно опрашивать сервер о состоянии этого конкретного датчика? G>>Я не думаю что это единственное о чем будет спрашивать клиент.
G>Возможно и не единственное. Но схема когда клиент раз в длительный промежуток времени делает запросы к серверу, а все остальное время ждет асинхронных данных от него, причем с минимальной задержкой, вполне себе валидна.
Ну и зачем серверу вести набор подключенных клиентов, заботится о мониторинге состояния клиентов, рассылать всем извещения, думать как поступать если извещения не успевает получить клиент и т.д. и т.п.? Ваша валидная схема сразу же приводит к куче проблем, создающих дополнительные сложности и ограничивающие масштабируемость сервера.
G>И если например клиенту нужно знать состояние тысячи из десяти тысяч датчиков, причем с минимальной задержкой, а клиентов сотня, то они просто заддосят сервер.
А обновления о тысяче изменений тысяч датчиков тысячам клиентов сервер не обломится рассылать? Надо оптимизировать обработку запросов, например можно вести список событий в системе, привязанных к некоторому абстрактному времени. При желании клиент может периодически запрашивать свежий набор изменений.
G>А схема с подпиской будет отлично работать.
В теории может быть, а на практике будут проблемы.
ЗЫ Есть ещё модель Service Bus, когда рассылкой сообщений между агентами занимается специально выделенная среда, но это скорее для взаимодействия между серверами.
Re[11]: [.NET] событийная модель в распределенной системе
Здравствуйте, genre, Вы писали:
G>Здравствуйте, Undying, Вы писали:
U>>В этом случае по каждому датчику будет возвращаться по 5-10 состояний с временем когда произошло переключение для каждого из них, в чем проблема-то?
G>А че тогда раз в час не спрашивать? Видимо требуется реагировать как-то на каждое изменение.
А если у вас датчики будут по 100 раз в секунду обновляться будете столько же раз запрашивать состояние и рисовать его на экране? Кому это нужно то? Запрашивайте раз в секунду и все буду счастливы, и юзер и зазакчик и сервер.
Re[15]: [.NET] событийная модель в распределенной системе
Здравствуйте, 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] событийная модель в распределенной системе
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, Aviator, Вы писали:
A>>Где в этих условиях указана время реакции клиента на события с сервера? C>клиенты WPF означает их отобразить
Мне это ничего не означает, могу только предполагать что хотел этим сказать автор.
Разве автор говорил, что ему нужно соединяться по HTTP? Если речь о работе через WEB, то, имхо, о lдетерменированном времени обновления данных надо забыть — ответ от сервера может дойти и за пол-секунды, и 10 секунд может ползти. А если всё хозяйство в локальной сети, то зачем websockets, а не просто TCP (если не UDP)?
"Нормальные герои всегда идут в обход!"
