Bt-teh.ru

БТ Тех
0 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Организация синхронизации данных клиент-сервер для мобильного приложения кратко

Организация синхронизации данных клиент-сервер для мобильного приложения кратко

Привет, Вы узнаете про организация синхронизации данных, Разберем основные ее виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое организация синхронизации данных,клиент-сервер для мобильного приложения , настоятельно рекомендую прочитать все из категории Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL.

Имеется клиент и сервер . Сейчас каждый хранит свои данные , которые внесены отдельно на клиент и отдельно на сервер.
Данные могут создаваться/изменяться/удаляться на клиенте и на сервере.

Изменения можно (в целевой модели) осуществлять как на клиенте так и на сервере (из под одной учетной записи, либо админом).
Необходимо описать как правильно синхронизировать эти данные.

Чтобы нагляднее описать что требуется, возьмем к примеру приложение инстаграм.
Я сделал фотку в инстаграме — она видна у меня, потом на сервере и у моих друзей.
Кто-то написал комментарий через веб версию и он отразился у меня и у друзей.
Кто-то лайкнул у себя — и опять по цепочке все обновилось — лайкнувший юзер, сервер, я и друзья.
Я затер свой коммент у кого-то и он затерся у всех кто его мог видеть.

Как реализовать подобную схему синхронизации?
Что для этого нужно?

Архитектурно возможно два решения.

Локальная структура хранит два идентификатора, один полностью локальный, другой — тот ид что пришел с сервера после создания.

Механизм такой: сделали что-то, есть подключение к инету?
ДА — отправляем на сервер — получили успешный ответ?
да — добавили в локальную базу с id который пришел с сервера.
нет — пишем в чем ошибка в лог, извиняемся перед пользователем (хотя схема другая,обычно все ок, и не ок только если сервер упал)
НЕТ — пишем в локальную базу, с пустым сервер ID

появляется подключение к сети
— отправляем порциями локальные объекты (если они до появления инета не были удалены) для получения нужных сервер ID
— запрашиваем список удаленных с сервера (авось под этой учеткой на другом устройстве чтото удалили) удаляем локальные объекты

Как только сервер получает данные, он сообщает по сокету всем пользователям которые онлайн и находятся в какой то связи с контентом пользователя что его делал.

У вас всего два метода синхронизации:
— http запрос который отправляет клиент для загрузки/отправки данных;
— PUSH уведомление которое отправляет сервер на клиент;

Пример:
1 . Об этом говорит сайт https://intellect.icu . Клиент А сделал фотографию.
2. Клиент А отправил фотографию на сервер.
3. Сервер получил фотографию
4. Сервер отправил PUSH уведомления клиентам B и C с инормацией "есть новое фото от клиента А"
5. Клиенты B и C получили уведомления.
5.1 Если пользователь(человек) находится в фото ленте, то клиент делает запрос на сервер, загружает фото и отображает ее.
5.2 Если пользователь находится, например, на экране настроек, то клиент отображает уведомление(тост) "есть новое фото от клиента А"

Метод 1 Одностороння синхронизация изменений состояний

Организация синхронизации данных клиент-сервер для мобильного приложения

Метод 2 Односторонняя синхронизация данных

Организация синхронизации данных клиент-сервер для мобильного приложения

  • пример

Комментарии

1. если устройство получило негативный ответ от сервера(отличный от 200 и после повтора передачи без синхронизации)
или у устройства нет доступа в интернет то все данные записывать в локальную базу

после появления интернет или при наличии таких данных определить разность ранее синхронизированных данных
и новых данных собранных offline

результатом этих сравнений должны быть объекты и три операции над ними добавление, обновление, удаление
необходимые для того чтобы базы были одинаковые

2. отправляем следующие данные
—с ид <0 (приложение все записи созданные в автономном режиме сохраняет с глобальным ид=0,
но передавать нужно с локальным ид со знаком минус)- если новый объект — использоваться может в связанных данных
(после передачи команды на синхронизацию и в случае успеха приложение должно обновить глобальные ид на серверные значения)
—с признаком обновления (приложение должно иметь флаг обновления к каждой записи синхнонизируемых сущностей)
данный флаг можно сбросить только после отправки команды синхронизировать и если она прошла успешно
—с ид в таблице удалений (приложение должно хранить все ид записей и название сущностей которые удаляются в автономном режиме)
после отправки команды на синхронизацию и в случае ее успешного выполнения приложение очищает список удаленных записей

3.отправляем команду на синхронизацию
в случае успеха загружаем все данные или загружаем измененные данные и удаляем служебные данные в приложении
(в этот момент формируется отложенная запись на синхронизацию в связанных аккаунтах через PUSH)

4.клиент хранит
1. новые записи должны иметь ид <0 и равным уникальному локальному номеру
2.удаленные записи должны храниться в таблице удалений
3. обновленные записи в автономном режиме желательно помечать признаком обновлений

5.названия операций
ins=1
upd=2
del=3

6.название сущностей и полей доступных для вставки или обновления (если запись нужно удалить то нужен только ид):
передавать данные нужно именно в этом порядке без названия полей- только данные

сущность1 [id ид.поля. ]
сущность2[id ид.поля. ]
сущность3 [id ид.поля. ]

т.о. синхронизация от устройства на сервер состоит из таких дейтвий
1. передать данные (при этом выволняются комплекс проверок на сервере)

2. сохранить изменения (выполняются изменения отсортированные по unixtime )
и ставятся изменения(синхронизвции через пуши) в очередь для связанных
с этим аккаунтом устройствами (аккаунтами)

3. если на сервере имеется запись с unixtime больше чем на устройстве,
то изменение или удаление данной записи игнорируется и такую запись
нужно устройству уже загрузить с сервера

4. после передачи и фиксации данных на сервере нужно получить
данные(из п3) от сервера и занести в локальную бд устройства
5. т.к нет обратной синхронизации,то желательно в конце выполнить полную загрузку данных
(для обновления ид),это нужно если не доставился, или не отправился пуш с запросом на обратную синхронизацию или не учитывались данные переданные
в пуш

примечания
1. отрицальный локальный ид используется в трех случаях
если добавляется новая запись — всегда
(должна быть обязательно передана раньше ее использования в других записях)
если обновляется или удаляется запись созданная локально, при этом передавать такую запись не имеет смыла в случае синхронизации по методу 2
если обновляется существующая запись но с указанием в поле на локальную запись

См. также

  • единая служба синхронизации ,
  • планирование заданий , планирование процессов ,
  • теория синхронизации , синхронизация данных ,
  • REST api
  • синхронизация и электропитание , синхронная передача сигнала ,
  • синхронизация в system r ,
  • синхронизация файлов ,
  • задача синхронизации , задача о стрелках ,
Читать еще:  Как отрегулировать напор воды в квартире редуктор

На этом все! Теперь вы знаете все про организация синхронизации данных, Помните, что это теперь будет проще использовать на практике. Надеюсь, что теперь ты понял что такое организация синхронизации данных,клиент-сервер для мобильного приложения и для чего все это нужно, а если не понял, или есть замечания, то нестесняся пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Базы данных, знаний и хранилища данных. Big data, СУБД и SQL и noSQL

Как синхронизировать клиента и сервер

Если вы создаете игру и останавливаетесь посередине, пытаясь добавить многопользовательские возможности (которые вы не планировали включать), велика вероятность того, что вы столкнетесь с трудностями, пытаясь заставить все работать правильно. Помните — подготавливаться надо заранее, и если ваша игра собирается быть совместимой с многопользовательскими возможностями, вы должны убедиться, что у вас есть прочное основание для последующей работы.

Начните с понимания того, чему вам предстоит противостоять, используя сеть, и что вы можете сделать, чтобы обеспечить правильную работу. Будет полезно посмотреть как используется сетевая архитектура клиент/сервер. В главе 5, «Работа с сетью с DirectPlay», объяснялись основы работы с сетевыми коммуникациями на стороне клиента и сервера, а сейчас пришло время посмотреть как сервер и клиент могут эффективно работать вместе с точки зрения игрового процесса.

Работаем вместе: клиент и сервер

Клиент и сервер непрерывно общаются между собой. Когда игрок (клиент) выполняет в игре какое-либо действие, информация об этом действии отправляется в виде сообщения серверу для проверки. Сервер, обеспечивая поддержку синхронизации, получает действия игроков, обновляет игровой мир и рассылает обновленное состояние игры клиентам. Таким образом, сервер управляет всем игровым миром, а клиенты являются простыми системами для сбора действий игроков (и отображения их результатов на экранах клиентов).

Типов сообщений, пересылаемых между сервером и клиентом, может быть очень много, но в хорошо продуманном проекте эти сообщения будет легко обслуживать. Сообщения могут быть следующими:

Запрос подключения . Присоединение к игре означает подключение к серверу. Однако, присоединиться может не каждый; к серверу уже может быть подключено максимально возможное количество игроков, или у игрока может не быть допустимой учетной записи. Как только клиент подключился, начинается настоящее действие!

Навигация . Игрок может перемещаться по картам, обычно используя клавиши управления курсором на клавиатуре или щелкая по требуемому месту на карте. Клиенты отсылают свои запросы на перемещение и ждут, пока сервер не вернет им сообщения об обновлении игрового состояния.

Сражения . Размахивание мечами и разбрасывание заклинаний, кажется, со стольким многим приходится иметь дело. Но если очистить все от шелухи, вы обнаружите, что битва это только лишь атакующий с его способом атаки и обороняющийся с его способом защиты. Клиенты только формируют запросы на сражения; работа сервера — получить запрос на сражение и преобразовать его в изменения игрового состояния.

Управление ресурсами . В мире, полном вещей, игроки хотят иметь возможность купить, продать, найти или использовать любой из ресурсов, до которых дотянутся их руки. Я начинаю повторяться, поскольку управление ресурсами исходит от клиента, и запросы отправляются серверу, чтобы быть использованными для обновлений.

Общение . Что за удовольствие от многопользовательской игры без взаимодействия с другими игроками? Персонажи говорят друг с другом, чтобы узнать важную информацию, или просто потрепаться. В любом случае, это вопрос отображения нескольких строчек текста. Это общение работает в обеих направлениях, клиенты отправляют текст серверу, а сервер возвращает им текст, который должен быть показан.

Обновление игрового состояния . Как упоминалось ранее, сервер должен предоставить всем клиентам возможность периодически узнавать состояние игры, и сообщение об изменении игрового состояния это просто билет. Сообщение об изменении игрового состояния обычно включает местоположение всех игровых персонажей, плюс информацию о предметах и других игровых ресурсах.

При использовании упомянутой выше сетевой архитектуры на ум сразу приходит пара вещей. Во-первых, поскольку только сервер ответственен за управление состоянием игры, все подключенные клиенты должны ожидать упомянутых периодических обновлений для поддержания хода игры.

К сожалению, скорость передачи данных по сети не позволяет осуществлять мгновенную передачу, поэтому данные, проходящие от клиента к серверу и обратно, задерживаются. Эта задержка в процессе передачи называется запаздыванием (latency), и это время ожидания может вызвать проблемы в вашей игре.

Поскольку только серверу позволено делать изменения в игровом мире, сервер должен подтверждать допустимость происходящих действий пользователей. Как видно на рис. 15.4, игроки сталкиваются с проблемой из-за задержки, между временем, когда действие было инициировано, и временем, когда оно происходит. Эта задержка действий называется отставанием (lag) и может сделать игровой процесс неустойчивым (и непригодным для игры).

Рис. 15.4. Клиент отправляет сообщение и ждет ответа от сервера, ощущая задержку передачи (отставание)

Рис. 15.4. Клиент отправляет сообщение и ждет ответа от сервера, ощущая задержку передачи (отставание)

Чтобы обеспечить плавность событий и помочь смягчить эффекты задержки и отставания, клиентам позволяется производить незначительные изменения в игровом мире между поступающими с сервера обновлениями. Эти небольшие изменения обычно являются только обновлениями перемещения персонажа. В этом случае клиент не ждет обновлений от сервера, чтобы переместить персонажи; клиент может только предположить, как обновлять все персонажи, основываясь на их последнем известном состоянии (рис. 15.5). Подобные предположения называются расчетом траектории (dead reckoning) и применяются в сетевых играх.

Рис. 15.5. Благодаря расчету траектории, идущий персонаж продолжает движение, пока сервер не сообщит, что персонаж остановился

Рис. 15.5. Благодаря расчету траектории, идущий персонаж продолжает движение, пока сервер не сообщит, что персонаж остановился

В более сложных действиях, таких как сражения, использование расчета траектории неприменимо. Сервер является верховной властью, и если системе необходимо определить кто, кого и как сильно ударил, она должна отправить запрос серверу.

Как упоминалось, вторая проблема при использовании сетевых систем — это отсчет игрового времени. Взгляните: попытка синхронизировать десятки клиентов практически нереальна. Каждый компьютер подключен к сети с различным временем запаздывания; некоторые клиенты дольше отправляют сообщения серверу и позже принимают их обратно от сервера.

На стороне клиента один игрок может выполнить перемещение точно в тот же момент, что и другой, но поскольку эти действиям требуется время, чтобы достичь сервера, у клиента с более быстрым соединением есть преимущество (рис. 15.6).

Рис. 15.6. У клиента слева задержка меньше, чем у игрока справа, поэтому его действия первыми достигнут сервера и будут обработаны раньше

Рис. 15.6. У клиента слева задержка меньше, чем у игрока справа, поэтому его действия первыми достигнут сервера и будут обработаны раньше

Читать еще:  Регулировка подачи воздуха в печь камин

Все сообщения, полученные клиентом и сервером, записываются вместе со временем их получения. Сервер использует это время, чтобы определить, как обновлять состояние игроков. Например, если полученное сервером сообщение не обрабатывалось в течение 100 мс, сервер компенсирует пропущенное время в ходе выполнения обновления. Тоже самое верно и для клиента. Если действие должно быть обновлено (особенно при использовании расчета траектории), это время (время, прошедшее с момента получения сообщения) используется для соответствующего перемещения персонажей.

Если вы оставляете важные решения (такие, как сражения) на стороне клиента, вас ждут неприятности, поскольку взломщики и мошенники будут использовать эти лазейки для получения преимуществ. Помните, что только сервер ответственен за отслеживание хода игры; клиенты — это просто порталы в игровой мир.

Теперь, рассмотрев совместную работу клиентов и сервера, пристальнее взглянем на каждую из этих систем.

Взгляд на сервер

Игровой сервер — это специализированная часть программного обеспечения. Ему не нужна захватывающая графика, воспроизведение мелодий или даже выделенные функции ввода. Серверу необходимо только обрабатывать получаемые от подключенных игроков действия и также часто отправлять обновления клиентам.

После запуска сервер попадает в цикл, непрерывно обрабатывая входящие сетевые сообщения, обновляя состояние всех подключенных игроков, основываясь на их последнем известном действии, и рассылая обновления.

Сервер получает несколько сетевых сообщений — запрос подключения, уведомление об отключении и действия игрока. Действия игрока целиком зависят от проекта игры, и в демонстрационной программе из этой главы включают только ходьбу игрока, остановку и атаку оружием.

Полученное от клиента сетевое сообщение помещается в очередь сообщений (message queue). Использование очереди сообщений ускоряет сетевые операции и оставляет больше времени для работы основного приложения (а не потока с кодом работы с сетью). Сервер управляет очередью сообщений (стеком сообщений), хранящей все входящие сообщения. Поступающее сообщение добавляется в очередь. Сервер постоянно извлекает наиболее старые сообщения и перенаправляет их различным функциям для обработки. Этот процесс обработки сообщений показан на рис. 15.7.

Рис. 15.7. Сетевые сообщения вставляются в очередь в порядке их поступления

Рис. 15.7. Сетевые сообщения вставляются в очередь в порядке их поступления. Очередь сообщений гарантирует, что следующим сервером будет обработано самое старое из сообщений

Имея дело с запросами на подключение игроков, сервер сначала проверяет, есть ли открытый слот для игрока. Если да, от клиента запрашиваются данные игрока, которые сохраняются в локальной структуре. Все присутствующие в игре игроки уведомляются, что к драке присоединился новый игрок, и игра продолжается. Слот освобождается когда игрок отключается.

Для улучшения синхронизации клиент и сервер вычисляют временную задержку получения сообщения. Вы увидите как вычислять задержку в разделе «Вычисление запаздывания» далее в этой главе.

Вскоре приходится иметь дело с действиями игрока; все действия игрока просто меняют состояние игрока. В рассматриваемом примере используются только состояния ходьбы, остановки, атаки и получения повреждений. Эти состояния используются в каждом кадре для обновления информации игрока. Получив действие игрока сервер отсылает его всем другим подключенным игрокам, чтобы они могли обновлять их игровые состояния (разумеется, между обновлениями сервера).

Кроме работы с сетевыми сообщениями, сервер обновляет состояние игроков. Если последним известным состоянием персонажа игрока была ходьба в заданном направлении, игрок продолжает движение в этом направлении. Сервер, как ответственный за все, должен выполнять проверку столкновений, чтобы перемещающиеся персонажи не ходили сквозь стены!

Для каждого имеющегося в игре действия и состояния вы добавляете к серверу логику для обработки персонажей. Например, состояние атаки требует, чтобы сервер отклонял последующие изменения состояния от игрока, пока состояние атаки не будет сброшено (через одну секунду). Когда клиент инициирует нападение, сервер вычислит, какие другие клиенты были поражены и уровень нанесенных им повреждений.

Реализация сервера проста. После того, как вы создали основу для работы, можно легко добавлять к серверу дополнительные возможности. Помимо добавления новых действий, которые могут выполнять игроки, вы можете добавить такие возможности, как управление учетными записями игроков. Однако, пришло время взглянуть на имеющиеся вещи со стороны клиента.

Взгляд на клиента

Установив соединение клиенту необходимо собрать информацию об управлении локальным игроком и отправить ее на сервер. В промежутках между получениями обновлений от сервера клиент предполагает (используя отслеживание траектории) как следует управлять всеми игровыми персонажами, основываясь на их последнем известном состоянии.

Например, все персонажи, шедшие при последнем обновлении, продолжают идти, пока сервер не сигнализирует, что их нужно остановить. Благодаря этому игровой процесс получается плавным, и с хорошим сетевым соединением обновления от сервера поступают достаточно часто, чтобы игра оставалась полностью синхронизированной.

Как показано на рис. 15.8, когда клиент выполняет изменение действия (такое, как ходьба в направлении, отличном от заданного в последнем известном состоянии), это изменение состояния немедленно передается серверу, который сразу же рассылает его всем подключенным клиентам. Благодаря этому синхронизация становится еще лучше.

Рис. 15.8. Клиент отсылает изменение состояния серверу только когда игрок выбирает перемещение в направлении отличном от предыдущего

Рис. 15.8. Клиент отсылает изменение состояния серверу только когда игрок выбирает перемещение в направлении отличном от предыдущего, что экономит время, поскольку не приходится пересылать одно и то же направление перемещения снова и снова

Если говорить об изменении действий игрока, какие точно действия может выполнять игрок? Например, перемещение. Когда игрок ходит по карте, направление его движения передается на сервер. Заметьте, что отправляется только направление движения.

Если вы позволите клиентам указывать координаты, когда они перемещаются, у мошенников возникнет искушение подменить эти значения. Вместо этого сервер модифицирует координаты игрока и отправляет эти координаты обратно клиенту (в этот раз не имеет значения, модифицирует ли мошенник эти значения, поскольку они не оказывают влияния на сервер).

Для определенных действий, таких как ходьба, клиентам разрешается изменять свое собственное состояние. В результате игроки могут перемещаться в промежутках между получением обновлений от сервера. Для таких действий как атака, изменение состояния только отправляется на сервер, который, в свою очередь, обрабатывает атаку и рассылает соответствующие изменения состояний всем клиентам.

Игроки могут выполнять обновления только каждые 33 мс. Это временное ограничение обновлений введено для того, чтобы клиенты не затопили сервер тысячами действий. Сохраняя минимальный уровень действий сервер может обрабатывать все более быстро и игровой процесс остается плавным.

Всякий раз, когда сервер отправляет клиенту критически важные обновления, клиент немедленно меняет состояние рассматриваемого персонажа или персонажей (здесь не требуется очередь сообщений). Это обновление может также затрагивать локального игрока, поскольку вы перемещаетесь вокруг и могло произойти несколько переключений действий из-за синхронизации клиента с сервером.

Читать еще:  Как сделать регулировка окна самостоятельно

Ладно, достаточно исследований; перейдем к созданию настоящей сетевой игры!

Настройка синхронизации времени с сервером

Сегодня востребовано большое количество технологий синхронизации часов, среди которых наиболее популярной является NTP-технология. Она позволяет получать данные о точном времени с помощью локальной сети или сети общего доступа без применения сложных настроек.

NTP-протокол синхронизации времени по сети даёт возможность настроить оборудование прямо через Интернет. Фактически процедура сводится в нескольким этапам: клиент запрашивает время на сервере и использует полученную информацию для часов на собственном оборудовании.

Особенности синхронизации времени с NTP-сервером

Кажущаяся простота процесса скрывает в себе много незаметных тонкостей и процедур. Так, например, существуют разные уровни NTP-сервера.

Серверы 1 уровня подключены непосредственно к атомным часам и обеспечивают максимально точную информацию. Серверы 2 и 3 уровней работают от серверов 1 уровня и могут выдавать информацию с небольшими погрешностями, которые неактуальны для обычных пользователей, но могут оказаться существенными для промышленных и специализированных систем.

Клиентское приложение по синхронизации времени выглядит несложным, но на самом деле оно не только дает данные о точном времени, но и компенсирует все возникающие задержки соединения, регулирует время так, чтобы не сбить другие процессы на сервере. Оборудование тактовой сетевой синхронизации разрабатывается по специальным стандартам, и к нему предъявляются повышенные требования по точности обеспечиваемых данных.

Специальные сервисы по синхронизации времени постоянно контролируют точность хода часов на оборудовании и корректируют данные при необходимости. Работа таких сервисов не требует большой мощности процессора и не занимает много оперативной памяти.

Чтобы синхронизировать время с NTP-сервером, необходимо выбрать источник. Процедура стандартной настройки синхронизации времени с сервером точного времени состоит из следующих действий:

  • на межсетевом экране запускается стандартный NTP-порт с разрешением на входящие и исходящие соединения;
  • определяется рабочий пдс-сервер (запись в командной строке: C:>netdom /query fsmo);
  • останавливается работа службы Windows Time (запись в командной строке: C:>net stop w32time);
  • проводится настройка внешнего источника времени (запись в командной строке: C:> w32tm /config /syncfrom _(источник)_);
  • активируется доступ для клиентов к домену (запись в командной строке: C:>w32tm /config /reliable:yes);
  • запускается служба Windows Time (запись в командной строке: C:>net start w32time).

Служба времени после вышеуказанных действий начнёт синхронизацию времени с указанным внешним источником. Установленный внешний сервер точного времени можно посмотреть с помощью записи в командной строке C:>w32tm /query /configuration.

После выполнения всех настроек рекомендуется проверить, нет ли в журнале событий ошибок. Настройку синхронизации времени с сервером на оборудовании достаточно провести единожды, после чего все данные будут обновляться автоматически.

Как синхронизировать клиента и сервер

Асинхронная телемедицинская система – многофункциональная система хранения, обработки, обеспечения доступа и обмена информацией. Она состоит из двух узлов: клиента и сервера, каждый из которых может частично выполнять функции другого узла.

Клиентское программное обеспечение располагается на машинах специалистов на местах. На них проводится сбор данных о пациенте, симптомах болезни и необходимая диагностика. Также на них проводятся сами консультации в текстовом, аудио и/или видео формате, отложено или он-лайн. На клиенте хранится локальная база данных пациентов и учетных записей сотрудников, пользующихся им.

Серверное программное обеспечение располагается на выделенной машине – сервере. Оно обеспечивает объединение клиентских машин в одно информационное пространство, хранит объединенную базу данных, проводит централизованную политику учетных записей, анализирует и собирает статистическую информацию, протоколирует проводящиеся конференции и консилиумы.

Принцип работы и взаимодействия системы в режиме:

В режиме «клиент-сервер» клиент и сервер располагаются в определенной иерархии – сервер, как центральный узел сети и как глобальный каталог информации, является главным по отношению к любому клиенту. При работе клиенты используют права и разрешения, полученные с сервера, а также подчиняются серверу в политике предоставления информации о пациентах. Обмен информации между клиентами осуществляется через сервер и проводится под контролем сервера.

В режиме «клиент-клиент» все клиенты находятся в равном положении в иерархии, поэтому, права и разрешения, а также политику предоставления информации, клиенты используют ранее полученные тем или иным образом от сервера. При проведении консультаций и консилиумов, инициирующий консультацию клиент берет на себя часть функций сервера – он определяет права и разрешения, а также политику предоставления информации непосредственно об объекте (одном или нескольких пациентах) консультации, ведет протоколирование обсуждения, хранит в своей локальной базе данных все результаты обсуждения, и при следующей связи с сервером передает ему всю информацию о проведенных консультациях.

Сервер, его задачи и возможности:

Сервер – значительно более производительная машина (или кластер машин), а поэтому, все статистические задачи, задачи централизации данных, задачи обеспечения информацией и правами доступа ложатся на него. Также предполагается, что сервер обладает широкополосными каналами связи с сетями Интернет, Интранет и др. Задачи сервера:

  • хранение информации: информация о пациентах, консультациях, учетных записях пользователей, политиках доступа к информации – все осуществляется с использованием базы данных.
  • предоставление хранящейся информации, выборка и статистический анализ, защита информации.
  • обеспечение централизованной работы с иерархией пользователей системы, доступом к ресурсам и информации.
  • обеспечение обмена текстовой, видео и аудио информацией в процессе общения клиентов между собой.
  • выборка для последующего анализа случаев заболеваний, диагностирование которых вызвало затруднение.
  • централизация обновления программного обеспечения клиентов.
  • оценка эффективности работы системы, производительности каналов связи с клиентами, контроль присутствия клиентов в системе с выводом уведомлений, замечаний и советов по усовершенствованию архитектуры каналов связи (то есть он сам определяет, будет ли возможна консультация в режиме он-лайн, как долго будет происходить синхронизация и прочий обмен информацией, а также он определит основные проблемы сети и пути их решения – например, расширение каналов связи с определенными клиентами).
  • обеспечение масштабирования системы – взаимодействие между серверами, предоставления клиентам списки специалистов системы для дальнейшего выбора из них участников конференций.

Клиент, его задачи и возможности:

Рабочие станции клиентов должны обеспечивать работу диагностирующего программного обеспечения, а также работу локальной базы данных, возможность проведения аудио и видео консультаций – для этого не требуются сверхпроизводительные системы, однако необходимо специальное аппаратное обеспечение (микрофон, видеокамера или web-камера и пр.). В зависимости от аппаратной части рабочей станции, ширины канала связи станции с сервером или другими клиентами, а также от работающего за ней специалиста, станция может выполнять следующие задачи:

голоса
Рейтинг статьи
Ссылка на основную публикацию
ВсеИнструменты
Adblock
detector