На основе Cookies, для сайтов с общим наддоменом 
  Хочу поделиться, как это удалось осуществить для одного проекта. Сложность использования других известных методов, заключалась в том, что проект не был привязан к единому доменному имени, а был локализован на сетке из поддоменов. То есть сайты проекта располагались на доменах третьего уровня. Данное обстоятельство вызывало некоторые неудобства из-за Same Origin Police.
  Разработчикам, которые ещё не сталкивались с подобными проблемами, пожалуй, будет интересно. Представьте себе веб-сервис (к примеру, социальную сеть) который должен в режиме online информировать пользователя о разного рода «новых сообщениях», «новых друзьях» и тому подобное. Веб-сервис, отслеживающий online индекс, какого-нибудь, Доу Джонса, или не дай бог, самой ММВБ. 
  Со страниц таких проектов, постоянно, с некоей периодичностью, отправляются запросы к серверу для получения актуальной информации. Более того, некоторые сервисы устанавливают постоянное соединение с клиентом, чтобы держать этого клиента в курсе своих тёмных серверных делишек в режиме реального времени. 
  Больное место подобных систем начинается, как это ни странно — с браузеров. С браузеров, которые поддерживают открытие страниц «в новой вкладке». И ещё больнее, когда в проекте, для различного рода информации, имеется отдельный тип страниц. (но это уже совсем другая история — история дизайна). 
  На самом деле, пользователю действительно неудобно постоянно кликать по ссылкам с текущей страницы, чтобы посмотреть «а ну ка, какую там оценку мне поставили». 
 И пользователь открывает сначала одну вкладку, для навигации, затем вторую вкладку, для отслеживания оценок, затем третью — для отслеживания новых сообщений. Количество одновременно открытых вкладок находится в прямой зависимости от величины желания пользователя «контролировать всё». 
  Сколько серверов нужно иметь чтобы быстро обработать запрос от каждого клиента с каждой такой открытой страницы? Тем более, если запросы идут асинхронные и с некоей периодичностью. 
  С необходимостью решения подобных проблем сталкиваются как растущие проекты, так и динозавры поглотившие web. 
  Для решения этой проблемы применимы, как минимум, два варианта: 
 — Увеличить серверную мощность, тем самым, снизив время обработки запроса клиента. Позволить себе такое могут немногие. 
 — Или же «образумить» запросы от самого клиента, что с любого взгляда кажется оптимальнее и целесообразнее. 
  Набирающий популярность Local Storage (и его модификации) не подходил по той простой причине, что на него также накладывалось правило ограничения домена (same origin policy). К тому же, необходимо было отслеживать состояние активных (открытых) вкладок, что требует дополнительной доли ресурсов. И, ко всему прочему, функционирует он, пока что, не во всех браузерах. По тем же причинам, на Flash также не было особой надежды, как и на другие вкусные фичи. Неплохой алгоритм, кстати, был описан вот тут. 
  В общем, после многодневного битья головой об стенку и обгрызывания краешков офисных столов, вспомнился древний и нативный браузерный механизм — Cookies. 
  Сейчас, после множества экспериментов, думаю, что есть место, где разгуляться фантазии для оптимизации данного механизма. 
  Метод разрабатывался для мессенджера, поэтому для самого мессенджера также устанавливалась кука, которая указывала в какой вкладке открыт мессенджер. При срабатывании интервала, вкладка проверяла, в том числе, в какой вкладке открыт мессенджер, и открыт ли вообще. И закрывала его у себя, в случае, если «хозяйкой» мессенджера она не явлалась. 
  Синхронизация состояния мессенджера осуществлялась с помощью Local Storage. В случае его отсутствия, ничего не оставалось делать, как производить запрос к серверу для получения последнего состояния. 
  Начну с недостатков: 
  Достоинства:   Для более детального ознакомления с описанным методом, можно скачать архивную копию. 
  PS: В архиве черновая версия.
  PPS: UPD 23.10.2014 версия 2.0 с блекджеком...