Здравствуйте, 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 раз в секунду обновляться будете столько же раз запрашивать состояние и рисовать его на экране? Кому это нужно то? Запрашивайте раз в секунду и все буду счастливы, и юзер и зазакчик и сервер.
Разве автор говорил, что ему нужно соединяться по HTTP? Если речь о работе через WEB, то, имхо, о lдетерменированном времени обновления данных надо забыть — ответ от сервера может дойти и за пол-секунды, и 10 секунд может ползти. А если всё хозяйство в локальной сети, то зачем websockets, а не просто TCP (если не UDP)?
"Нормальные герои всегда идут в обход!"
Надо оптимизировать обработку запросов, например можно вести список событий в системе, привязанных к некоторому абстрактному времени. При желании клиент может периодически запрашивать свежий набор изменений. 