Добрый день! помогите пожалуйста, есть таска и имеется такой пункт

- 3. Периодически проверять соединение между клиентом и сервером при помощи запросов, которые ничего не меняют.
Как это реализовать?

Нашла информацию по возможности использовать heartbeat, который как раз должен регулировать интервал проверки соединения, но примеров как это сделать нет.
Я сделала так:
async def wshandler(request: web.Request):
resp = web.WebSocketResponse(heartbeat=1)
...
...
но непонятно как это проверить, где-то должна отображаться в логе эта проверка соединения? В консоли сервера нет, в инструментах разработчика клиента (F12 - сеть) ничего не увидела.
Подскажите куда копать?

это что за язык вообще?

питошка ой, пойду в джанго группу сорри

Так а для чего проверять? Ws и можно применять чтобы иметь "постоянное соединение"

вообще у нормальных серверов есть таймаут на длительность соединения, чтобы не держать миллион открытых соединений

А разве нельзя поставить обработчик на отключение?

https://datatracker.ietf.org/doc/html/rfc6455#section-5.5.1 до Pong можешь прочитать и это: https://developer.mozilla.org/en-US/docs/Web/API/WebSocket/close https://www.rfc-editor.org/rfc/rfc6455.html#section-1.4

И что ты этим хотел сказать? Я в курсе про close. Если вкладку в браузере закроешь - тебе прилетит отключение, на которое можно поставить обработчик. Так сути вопроса не меняет.

это где ты про вкладку такое нашёл??

Я ставил подключение по сокетам между сайтом и серваком и ловил отключение при закрытии вкладки

ща чекну

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

А разве на сокеты нельзя хедеры ставить для предотвращения не тех подключений?

Я бы не сказал, что это распространенное явление по сокетам

А что делать в ситуации, когда клиент или сервер отвалился, не закрыв соединение?

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

Ws создаёт подключение на машине, которое попадает под "детект" самого сервера(кода) или я что-то неправильно понимаю?

что значит "не тех", вот IoT, например работать по WS может

сервер хрен с ним, реконнект только запили

Ещё раз - хедеры нельзя добавить?

подключись по WS и выключи свой пк или ноут, что там у тебя.

какиех хедеры?

Не, у меня и так ПК настрадался от отключения электричества, что даже ИБП купил. Ради практики ПК гробить не буду

ну просто убить процесс попробуйте

Ладно забей, пруфоф на хедеры я не нашел

я могу ещё раз переспросить: о каких хедерах идёт речь?

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

О подобных обычным post get запросам

Пока не у ПК

а они в WebSocketах есть?

Пруфоф на наличие не нашел, я же сказал. Но некоторые источники утверждают, что браузеры не поддерживают хедеры на сокетах

и как они могли бы решить проблему мёртвых соединений?

господи, я вам спеку кидал почитать

Эту - никак. Но ты добавил проблему того, что подключится могут все, и я на это осмелился ответить

а это разве проблема?

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

Ты че первый день в чате? Тут тех кто осмеливается отвечать не любят)

прям не любят?

.

Он имеет ввиду, что не только браузеры умеют в работать с вебсокетами

А, понял

http заголовки на стадии хендшейка? Мы же о них?

А вот тут я не уверен, что это будет довольно быстро, если на стадии рукопожатия

Но вообще да, я это имел ввиду

Всм не быстро?

Я сказал, что не уверен, это будет быстро, если добавить кастомные хедеры

Хендшейк работает через http, значит подчинается всем правилам http протокола

А я не понял что значит "быстро" или "не быстро"

Тип передаваемых данных будет больше, а это вес

Не, всё быстро будет. Заголовки много места не занимают

Является ли это решение "Фильтрации" всех пользователей, чтобы отсечь "ненужных"?

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

Ну, значит решение.

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

А вот на это я не бежал отвечать, так что оставлю это остальным экспертам.)

отключение интернета, вылет браузера, отключение питания - множество сценариев, короче говоря

Кста, можно попробовать как с jwt.

м?

В плане отключать и делать новые подключения через время, а в это же время на сервере удалять "старые" подключения. Точную реализацию я пока е сформировал, но идея есть

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

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

Грубовато, но почти да. Как при token и refresh токен. Если сервак упадет-он просто принимать подключения не будет, если поднимается - будет в базу писать. И поставить тайм-аут на проверку из базы сокетов со временем создания и удалять их по истечении.

Так я тебе говорю про решение мертвых

Я к теме, а не лично тебе, сори за реплай

А ок.

Andrii

https://stackoverflow.com/a/23240725

если сервак упадёт, то все соединения сбросятся

А что мешает делать реконнект со стороны клиента? И все равно все подключения можно через try catch удалять, как и из базы

это механизм таймаута, но с базой, верно?

Как с jwt

Я бы сказал механизм jwt, но с тацмаутом

А именно token и refresh_token

А как можно подключение сохранить в бд? Или я что-то не понял

Инфу о нем, как минимум на сервере держать массив о сокетах и id к ним, а в базе инфа об id. И дату тоже.

А проверку сокетов по истечению таймаута как будешь делать?

чем это отличается от простого таймаута?

По времени создания в базе. Просто вытаскивать все у кого время создания - и условие.

Ты просто будешь после таймаута отключать соединение? Или как, я не понял

Делать тайм-аут на каждый сокет ты имеешь ввиду?

После таймаута лезть в базу и доставать все "устаревшие" подключения. Хотя идея с таймаутом на сокет - тоже мне нравится

да

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

Крч, да. Делаем со стороны клиента запрос на Коннект и тайм-аут на перезапрос подключения. В это же время со стороны Бека на каждое новое подключение делаем тайм-аут времени жизни - условно 10 минут. Условно говоря - у клиента подключение должно жить 10 минут, и потому делаем либо через interval или через timeout запрос на переподключение. На беке же как тайм-аут срабатывает - удаляем подключение. Как у клиента - делаем запрос на подключение. Итог - старые удаляются по времени. Новые будут создаваться только если клиент активен

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

А меня, наверное, люто ненавидишь😁?

Фидбек?

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

Я уже от ДБ отказался

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

Подключаемся и через таймут со стороны Бека разрываем соединение. А со стороны клиента во время подключения делаем тайм-аут на переподключение

Ещё лучше

то есть вернулись туда откуда начали?

В плане

https://t.me/nodejs_ru/898147

Я из сообщения не понял, что идёт проверка на"живость" соединения

я не писал про проверку, в этом сообщении, потом писал.

Видимо пропустил