Мониторинг вкладок браузера с localConnection и смысл, когда пользователь закрывает вкладку

Question

В моем приложении окно браузера соединяется с длинным опросом (кометой) с сервером. Если пользователь открывает несколько вкладок браузера, только одна из них (называемая главной) связывается с сервером и служит прокси для других вкладок. Я хочу использовать flash localConnection для обмена данными между вкладками.

Что происходит, когда пользователь закрывает главную вкладку с сеансом кометы? Я могу использовать javascript с событием unload, чтобы сообщить другим вкладкам, что главная вкладка закрывается, а затем закрыть localConnection, но событие unload ненадежно. Я могу использовать опрос для наблюдения за объектом соединения с основной вкладкой, но он звучит грязно.

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

Если пользователь закрывает вкладку, не имея возможности флэш-памяти закрыть локальное соединение, это приведет к утечке памяти?

Спасибо

Answer 1

Поскольку LocalConnection использует строки идентификаторов для обработки обнаружения, должно работать следующее решение:

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

Подобный эффект может быть достигнут без обращения к событию unload (если это нежелательно). Когда пользователь закрывает главную вкладку, любое приложение, пытающееся подключиться к LocalConnection, которое оно использовало, получит исключение. Вместо того, чтобы выдавать ошибку, ведомое приложение может вместо этого сделать вывод, что это исключение означает, что мастер закрылся. Затем он берет на себя роль мастера и регистрирует новое LocalConnection с тем же именем, что и у мастера. Остальное следует как указано выше.

Answer 2

Я тоже думал о похожей стратегии.

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

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

Спасибо

Answer 3

Это очень интересная проблема. Я наполовину испытывал желание написать что-то, чтобы посмотреть, как это будет работать! (Если бы только у меня было время!)

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

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

Мне кажется, что поток логики для каждого SWF-файла должен выглядеть примерно так:

• Проверьте, не первый ли я (подключился к каналу управления)
• Если это так, запустите канал управления и скажите JS запустить кометное соединение через ExternalInterface
• Если нет, подключитесь к каналу управления и запросите двустороннее подключение (в этот момент каждый подчиненный SWF-файл будет генерировать случайный идентификатор и отправлять его ведущему устройству - этот идентификатор будет использоваться в качестве имени LC для данных, поступающих из хозяин рабу)

Что касается самовосстановления, я полагаю, вы могли бы сделать что-то похожее на цепную букву. То есть, поскольку каждый SWF-файл подключается к ведущему, он может получить список ведомых. Если соединение когда-либо прервалось, каждый клиент посмотрел бы, где он находится в списке. Если это был первый ведомый в списке, он стал бы ведущим - перезапустил канал управления и сказал JS запустить новое соединение с кометой. Затем каждый ведомый сервер увидит, что сервер вернулся, и вытеснит теперь ведущего из своей цепочки.

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

Надеюсь, это поможет!