Одна из наиболее заметных тенденций современного Интернета — ослабление роли «классических» десктопных мессенджеров, до недавнего времени безраздельно господствовавших на компьютерах пользователей, и возрастание роли мобильных и веб-клиентов.
Последние приобрели особую популярность благодаря почтовым сервисам нового поколения, а также социальным сетям.
Не осталась в стороне и компания Mail.Ru; в 2008 году была запущена первая версия Веб-Агента Mail.Ru (далее просто Агент).
Однако если пользователь может даже не задумываться о разнице между автономным приложением и веб-клиентом, то для разработчика разница очевидна.
А вот трудности и проблемы, которые придется решать путем изменения философии взаимодействия отдельной программы с браузером, могут оказаться менее прозрачными.
Первым «врагом» разработчика в этом случае является сам пользователь.
Вместо того, чтобы сосредоточиться на общении со своими друзьями на странице в социальной сети или электронной почте, он кликает по ссылкам и бродит по страницам.
Это означает, что вам необходимо запомнить полное состояние клиента и восстановить его на следующей загруженной странице.
И как только эта проблема решена, пользователь вспоминает, что его браузер поддерживает вкладки, и начинает открывать, например, письма в новых вкладках.
В этом случае мы должны синхронизировать состояние клиента, с которым в данный момент взаимодействует пользователь, со всеми открытыми копиями клиента — чтобы клиент выглядел одинаково в любой вкладке.
В общем, перед разработчиком стоит целый комплекс проблем сохранения/изменения и синхронизации состояния клиента.
История развития Агента во многом совпадает с историей преодоления разработчиками перечисленных проблем.
В процессе мы столкнулись со многими ожидаемыми и неожиданными трудностями, которые нам пришлось либо преодолевать, либо обходить.
Попробую в общих чертах описать, как это выглядело на практике.
Однако сначала давайте определимся с основными понятиями, которые мы часто используем в нашей рабочей группе.
Чтобы понять эту статью, достаточно запомнить всего четыре термина: это состояние , событие , маршрутизатор И клиент .
Состояние — набор свойств Агента, определяющих его текущий внешний вид (представление).
К таким свойствам относятся список открытых диалогов, признаки текущего диалога, наличие непрочитанных сообщений в открытых диалогах, состояние псевдоокна Агента (свернуто/развернуто), уведомление о наборе текста и т.д. Статус можно изменить события , которые содержат информацию о том, что именно изменилось в состоянии.
Событие может быть инициировано как сервером (например, когда кто-то написал сообщение пользователю), так и клиентами.
Клиент Это программа, которая запускается в браузере пользователя и отображает пользовательский интерфейс в зависимости от состояния.
Кроме того, клиент может генерировать события — например, когда пользователь открывает или закрывает диалог, разворачивает или сворачивает псевдоокно.
Окончательно, маршрутизатор — это своего рода «черный ящик», к которому подключаются все клиенты, и который всегда «знает» последнее состояние Агента.
Основная задача роутера — получать события от сервера, а также клиента, с которым в данный момент взаимодействует пользователь, и отправлять их другим подключенным клиентам.
Таким образом, маршрутизатор обеспечивает синхронизацию состояния между всеми копиями клиента.
NB: Вообще, с точки зрения сетевой терминологии, наш роутер правильнее было бы называть хабом, но исторически сложилось так.
:) Этап I. Синхронизация серверов.
Первым решением, которое мы попробовали, была синхронизация серверов, то есть «настоящие» выделенные серверы выступали в роли маршрутизаторов.
Преимущества казались очевидными: независимо от того, с какого браузера или компьютера осуществлялось подключение, состояние всех клиентов синхронизировалось.
Простота дизайна клиента тоже была очень соблазнительна — он оказался действительно «тонким», ведь его задачей было лишь взаимодействовать с пользователем и рисовать изменения состояния.
Однако почти сразу же возникли два узких места:
- задержки сервера и состояния перезаписи;
- задержки в сети.
Как только пользователь начинал общаться с большим количеством контактов и делать это быстро, синхронизация «разваливалась» под нагрузкой сети, особенно при большом количестве открытых окон — ведь нужно было доставлять одни и те же события отдельно в каждое окно.
Помимо низкой скорости ответа, такой подход создавал большую нагрузку на роутеры, поэтому мы от него быстро отказались.
Этап II. Передача синхронизации клиенту.
Очевидным ответом на проблемы с синхронизацией сервера была передача этой задачи клиентскому компьютеру.
Здесь и вычислительная мощность, не разделяемая с другими пользователями, и отсутствие длинной «руки», присущей системе «браузер1 — сервер — браузер2».
В качестве решения был выбран Adobe Flash, а точнее его класс.
Флэш-локальное соединение , разработанный специально для диспетчеризации событий.
В этой архитектуре первый запущенный экземпляр клиента выступал в роли маршрутизатора.
Каждая новая копия клиента проверяла, был ли уже создан маршрутизатор, подключен к нему, и начинала передавать и получать состояния с него, а не напрямую с сервера.
По сути, получился «тонкий клиент с толстыми элементами».
:) Такая реализация принесла облегчение по сравнению с синхронизацией сервера, но довольно быстро мы столкнулись с другими трудностями — на этот раз, к сожалению, «похороненными» внутри самого Flash Player. Для начала выяснилось, что внутреннее хранилище Flash Player не позволяет часто записывать и читать данные и хранить большие объемы данных, что было типичным сценарием при интенсивном использовании Агента.
Однако самые большие проблемы начались после очередного обновления Flash Player, когда по неизвестным причинам резко упала скорость Local Connection, а сигнал от одной вкладки к другой начал буквально «теряться в проводах».
В сочетании с не особенно высокой скоростью Flash Player это часто приводило к значительной рассинхронизации.
Этап III. Синхронизация клиентов с использованием HTML 5. Выпуск HTML 5 и реализация его поддержки в большинстве современных браузеров предоставили разработчикам веб-приложений новые инструменты.
Лучшей новостью для нас стало появление собственного локального хранилища браузера.
Теперь без использования внешних технологий стало возможным хранить около 5 МБ данных локально и обеспечивать быстрый доступ к ним для каждого клиентского экземпляра.
По сути, это то же самое Local Connection, только гораздо быстрее и надежнее, а также без ограничений на чтение и запись.
На практике это позволяет нам отказаться от маршрутизатора и хранить общее состояние, которое «видится» и легко модифицируется всеми экземплярами клиента (конечно, это работает только в рамках одного браузера).
Однако наряду с новыми возможностями возникли и новые трудности.
Например, для синхронизации состояний между разными доменами, на которых размещаются страницы с агентом, создается iframe, на который распространяется правило ограничения домена (та же политика происхождения).
Чтобы обойти это ограничение, мне пришлось использовать библиотеку EasyXDM и транспорт postMessage. Интересно, что эта библиотека позволяет осуществлять междоменный обмен сообщениями с проверкой отправителя и получателя.
Сейчас это основной метод синхронизации, хотя в старых браузерах, не поддерживающих локальное хранилище, мы по-прежнему вынуждены использовать синхронизацию состояния через Flash Player. И напоследок скажу.
Внешний вид Веб-Агента на данный момент не совсем соответствует нашим представлениям о красоте, но мы активно над этим работаем и совсем скоро будем готовы официально представить новый дизайн.
Ждите анонсов! Илья Наумов, Менеджер проекта Агент Mail.Ru Теги: #JavaScript #mail.ru #im #Mail.Ru Агент #Mail.Ru Агент #mail.ru агент #mail.ru агент #Mail.Ru Агент #веб-агент #веб-агент
-
4Sync Упрощает Онлайн-Хранилище
19 Oct, 24 -
Катушка Тесла Из Строительного Магазина.
19 Oct, 24
