Вебсокеты и сворачивания браузера

Запоминай время разрыва соединения. Потом выдавай все новые сообщения, которые после этого времени пришли.

Элементарно же!

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

Ещё и хранить их где-то.

бд с таблицами MEMORY, проще некуда

нумеруй сообщения.

im

mail

pubsub

В хроме есть нотификации, используй его API, работают даже если свернут, а больше никак.

о новых сообщениях по сокету можно только уведомлять.
после каждого такого сообщения форум дернет с серва json с обновами.

сообщения нумеровать, так фоум узнает пропустил он что-то или нет. сможет запросить дельту.

о новых сообщениях по сокету можно только уведомлять.

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

Пока сделал так: при подключении к вебсокетам клиент один раз дёргает дельту и подтягивает её «старым» способом. А дальше уже ловит обновления из вебсокетов.

все просто

выводишь всегда первые 10, а остальное по запросу плюс логика пометить как прочтенные

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

Естественно! Обычные форумы-то так и работают. Все равно у тебя будет БД с сообщениями.

Или ты хотел "настоящий realtime"? Тогда нафиг не нужно думать о потерянных сообщениях.

У меня сервер вообще не беспокоится о том, сколько там юзеров читают тред.

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

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

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

И фиг с ним, форумом! Ведь бывают более напряжные вещи — скажем, видеостриминг. Чтобы не было извращений, просто сервер бы мультикастами раздавал видеопоток, а все, кому надо, в реальном времени его бы забирали. А не так, как сейчас — через жопу.

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

нужно чтобы именно клиент дёргал бы сервер.

а вот чтобы клиент НЕ дёргал бы сервер *каждую* секунду, а лишь только в нужные моменты времени — вот именно для этого и делаются всякие там WebSockets и прочии подобные штуки :)

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

И сфига ли вообще клиент должен дергать сервер? У тебя ж вебсокеты! Это сервер должен отдавать новое клиенту! Клиент же по этим вебсокетам лишь выплевывает на сервер новые сообщения/темы.

Поддерживаю. Данные передаются на сервер и забираются с сервера по единому апи. Через вебсокеты - уведомления. Кстати, так мы решали попутно еще какую-то проблему, но я забыл какую (вспомню, напишу).

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

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

В том-то и проблема, что у меня нет ни логинов, ни паролей, ни временных меток. Анонимус заходит на страницу и получает с неё сообщения.

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

Вебсокеты — это отличная возможность построить нормальное асинхронное приложение без необходимости постоянно дергать сервер POST-запросами.

Еще бы придумать, как через вебсокеты видео передавать...

А POST-запросы нафиг не нужны уже. Есть вебсокеты: открыл 1 раз, и работай. И не нужно лишних данных туда-сюда посылать...

А, вона как! Ну, тогда насрать на пропущенные сообщения. Просто сообщай всем остальным, что чувак отвалился.

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

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

Просто и понятно.

Сейчас думаю над двумя вариантами: либо как сейчас, либо действительно использовать вебсокеты только для уведомления браузеру «пора дёрнуть апишку и обновиться». Но второе чуть увеличит нагрузку на сервер, сейчас ведь сообщение он отправляет в центрифугу (сервер вебсокетов) один раз и точка, а так каждый будет дёргать проверку на обновление.

Я сейчас так и делаю. Только время лежит не в localstorage, а в жабаскриптовой переменной.

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

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

Я не предлагаю все в одну кучу мешать. Только вебсокеты — и никаких POST-запросов!

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

Ну т.е. ты предлагаешь вебсокет-приложение. Думается мне, это не случай ТС. И я реально не видел пока ни одного такого приложения, кроме примеров уровня хеллоуворлдов. Подозреваю, что это из-за их ненужности в реальной жизни.

Ага, и я про то же. Если замечу проблемы, так и сделаю. А пока оставил как есть.

У меня будет такое приложение. Управлялка моторами уже работает. Остается лишь видео прилепить. Потому что хочу уйти от mjpeg'ов, т.к. быдлокодеры тормозилы до сих пор не научились запилить нормальный сборщик мусора! А при перезагрузке iframe'а с видео получаем некошерное моргание.

Триггер на закрытие страницы криво работает и своеобразно на разных движках... Особенно замечались (не недавно) глюки на webkit и яблочных решениях.

Ну, ХЗ: у меня на всех огнелисах при попытке нажать ctrl+w или ctrl+q на недописанном сообщении на ЛОРе выскакивает окошко, которое просит подтвердить, что я действительно хочу уйти со страницы.

Вот первый же по списку из выдачи гугола:

window.onbeforeunload = function (evt) {
 var message = 'Did you remember to download your form?';
if (typeof evt == 'undefined') {
 evt = window.event;

}
 if (evt ) {
   evt.returnValue = message;
 }

    return message;

}

А нам тупо нужно в localstorage запихнуть json с нужными величинами. Фигня!

А POST-запросы нафиг не нужны уже. Есть вебсокеты: открыл 1 раз, и работай. И не нужно лишних данных туда-сюда посылать...

у тебя GSM-модем чтоли? трафик экономишь? :-)

нужна надёжная и чётная работа. и она достигается POST-запросами через ясное REST API ..

websockets лишь помагает правильно оптимизировать количество этих POST-запросов от клиента (подсказывает клиенту чтобы чтобы количество POST-запросов было бы не слишком много в минуту).

Есть вебсокеты: открыл 1 раз, и работай.

почитай современный HTTP-протокол как реализован — там даже если будешь делать несколько последовательно HTTP-запросов — всё равно TCP-соединение будет для всех них открываться только одно.

а в HTTP/2.0 — вообще происходит мультиплексирование

почитай современный HTTP-протокол как реализован — там даже если будешь делать несколько последовательно HTTP-запросов — всё равно TCP-соединение будет для всех них открываться только одно.

Ссылку можно?

у тебя GSM-модем чтоли? трафик экономишь? :-)

Нет, мне нужно нормальное асинхронное приложение. Я не собираюсь с частотой 50Гц запросы слать, чтобы минимизировать задержку!

нужна надёжная и чётная работа. и она достигается POST-запросами через ясное REST API ..

Это — тупняк. Прошлый век. Годится лишь для форумов и всякой подобной шняги, где и полминуты задержки — фигня.

почитай современный HTTP-протокол как реализован — там даже если будешь делать несколько последовательно HTTP-запросов — всё равно TCP-соединение будет для всех них открываться только одно.

Да что ты говоришь! firebug совершенно иное мне показывает!

И вот еще одна задача вебсокетов — выкинуть ненужный мусор. Ты когда POST-запрос отправляешь, помимо тела запроса (пусть это будет команда, скажем, "GO") отправишь еще куки, шапку и т.п. В итоге вместо двух байт отправится офигенный пакет! И если тебе нужна задержка меньше 10мс, ты будешь вынужден минимум 100 раз в секунду это слать! Трындец же!!!

Я не собираюсь с частотой 50Гц запросы слать, чтобы минимизировать задержку!

Тебе и не нужно. Ты будешь слать по вебсокету просьбу обратиться к серверу.

Ну и на кой черт это извращение, если я сразу по вебсокету могу сообщение послать без необходимости лишних соединений? Это и шустрей, и надежней, и проще!

надежней

В чём?

Ты стопудово знаешь, когда у тебя клиент отвалился и когда приконнектился. Без армии скаковых коров!

Если ты используешь http, тебе это и нужно знать.

Есть вебсокеты: открыл 1 раз, и работай. И не нужно лишних данных туда-сюда посылать...

А через какое-то время оказывается, что в приложении реализован свой бинарный http-over-websocket с разными типами запросов и тому подобным.

Хотя для некоторых задач, наверное, вполне подойдёт.