Разрабатываеться распределенная система.
Есть сервер который постоянно получает входные данные и их обрабатывает, и есть 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 в секунду.
