Хммм...

я ведь написал, что сервер 3rd-party, со своим сервером все тривиально

Я без малейшего понятия что понимается под словом «сервер» в данном случае. В моём понимании «свой сервер» это машина с виртуалками в неком ДЦ, на колокейшоне. При чём сама машина это моя собственность, просто размещена там. Виртуалки полностью под нашим контролем, всё что там установлено ставили мы либо разрабатывали мы. Т.е., все настройки и самих систем и прикладного софта целиком и полностью наши. Вот вообще все. Ну может быть и не виртуалки, это не важно. Иногда мы идём навстречу заказчикам и выделяем им по отдельному физическому серверу. Если у заказчика на это есть деньги. Что там в случае с localhost я даже догадываться пытаться не буду. Или что там с кривой реализацией.

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

Сам браузер пинг-фреймы не шлёт. Этим занимается сервер. Браузер только возвращает pong-фрейм, причём самостоятельно и без участия или уведомления пользователя. Пользователю и знать об этом ненужно, не его дело. Но коммуникации контролирует сервер. Реализация ping-pong для сервера штука сравнительно простая. По крайней мере, мы работаем с библиотеками libwebsockets (каноничная реализация, для «больших систем»), cwebsocket для систем типа OpenWRT, всё работает нормально на стороне сервера, всё отслеживается. Если хочется чисто свою реализацию (хотя, зачем, для той же OpenWRT cwebsocket выше крыши), то вот человек свой вариант написал для OpenWRT с поддержкой ping-pong https://istarik.ru/blog/programmirovanie/73.html Правда, я без понятия зачем он это сделал, но посмотреть как на стороне сервера реализуется ping и обработка pong там можно. Наверное, человек хотел просто разобраться как это работает. Не знаю.

Собственно, самое главное здесь в другом. Ссылок выше вполне достаточно чтобы написать нормальный сервер, который будет гарантированно работать, а не рвать соединение через минуту. Они там чё, подозревают Вас в организации DoS/DDoS что ли, чтобы закрывать так соединение? Так что, либо с хостером проблема, либо свой сервер надо писать и ставить туда. Но нормального тут нет ни чего.

Заодно замечу что я не припоминаю чтобы я писал где-то что из браузера ping frame шлётся. Если Вы читали RFC 6455, то там явно сказано в п. https://tools.ietf.org/html/rfc6455#section-5.5.3:

If an endpoint receives a Ping frame and has not yet sent Pong frame(s) in response to previous Ping frame(s), the endpoint MAY elect to send a Pong frame for only the most recently processed Ping frame.

Endpoint это и есть браузер. Но ни как не сервер. Так что, я такой дури что типа из браузера ping frame шлётся и не писал и не собирался. Я читал RFC 6455.

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

Такие вещи рано или поздно плохо заканчиваются, но дело Ваше. Я бы поопасился такой реализации в продакшоне. Какие там ещё косяки могут быть, это тема отдельного разговора.

и давайте плиз без оскорблений и гонора - ато напоминаете небезизвестного столярова, а это фу

Простите, я без понятия кто этот ваш Столяров и чем знаменит, но когда пятизвёздочный на ЛОРе прилаживается срать в уши насчёт реализации TCP, его ловят за руку и суют носом в его же говно (враньё), а он вместо того, чтобы как мужик включает тут сказки про «переход на личности», то вот лично для меня такое поведение коньяка в отношении стека TCP/IP да, является оскорбительным. Мне было бы похрен, если бы мы обсуждали сиськи или котиков. Даже было бы похрен если бы обсуждали патчи KDE под FreeBSD. Даже можно было бы поспорить с pon4ik про горизонтальное масштабирование серверов websockets на С. Хотя, где горизонтальное масштабирование и где например, OpenWRT? =)))

Понимаете? Но когда коньяк выдаёт что-то типа того, что он нёс выше, то вот это и является оскорблением. Ведь потом кто-то найдёт же в гугле эту тему и скажет «блин, да ЛОР-регистранты настолько тупы, что даже не понимают как TCP работает...». Вот это было бы стыдно, да. А остальное это было не оскорбление. Это была констатация печального факта и не более.

Ээээ... Поправлю.

чтобы как мужик

Надо читать «вместо того, чтобы как мужик признать свою неправоту, т.к. со всяким бывает», включает тут сказки про «переход на личности»... И далее по тексту.

Надеюсь, это понятно.

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

Вот почему.

библиотека для WebSocket сервера

Но, если коротко, то для клиентской части пофиг какая либа использована. Выбор либы зависит от Т.З. и чего там использует заказчик. Хреновая идея заказчику, сидящему на Qt/KDE предлагать решение с GTK и наоборот. Заказчик не оценит.

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

С горизонтальной масштабируемостью не всегда нужно бороться, т.к. не всегда она нужна. Например, при реализации сервера на той же OpenWRT. Кстати, не видел в таких юзкейсах реализаций на питоне и перле почему-то... =)

Ну а страданиями обезьяны, у которой внезапно повысилось wtf p/s при взгляде на код, можно пренебречь. Можно уволить эту, бестолковую обезьяну и нанять толковую. Вопрос только в деньгах.

Примерно вспомнил о чём речь, но к чему это в посте про хартбиты vs keep alive всё равно не догнал :)

С горизонтальной масштабируемостью не всегда нужно бороться, т.к. не всегда она нужна. Например, при реализации сервера на той же OpenWRT. Кстати, не видел в таких юзкейсах реализаций на питоне и перле почему-то... =)

Дык ктож спорит, в основном посыл был - собирать нефункциональные требования до старта проекта. И никто не спорит, что компилируемое обычно вертикально лучшее умееть, но, дороже, но не дороже чем разросшееся динамическое не покрытое тестами хотя бы на 90%.

Дык...

Примерно вспомнил о чём речь, но к чему это в посте про хартбиты vs keep alive всё равно не догнал :)

Я и спорить-то не собирался, если честно. Вы во многом правы. Просто так вышло, что в тот момент когда тот тред, на который я дал ссылку обсуждался, у меня в реале были примерно такие же обсуждения по поводу websockets, C и вот этого вот всего. =))) Совпадение позабавило.

А тут вон, человек пишет про сервер, который рвёт соединения раз в минуту аки Тузик грелку. Ну... Второго такого совпадения я уже просто не мог пропустить. =)))

Второй момент:

А тут вон, человек пишет про сервер, который рвёт соединения раз в минуту аки Тузик грелку. Ну... Второго такого совпадения я уже просто не мог пропустить. =)))

Тут речь скорее про нештатные ситуации, например - если QoS у хитрого роутера сглючил и он профукал пару пакетов. Или, например когда произошёл сбой по питанию в интересный момент. В проде такое ловится крайне редко, но когда ловится кастомер разбрызгивая слюной вопит какого дьякона у меня ваше убогое ПО зависло на 2 часа, а народ чешит репу ибо в логах всё как бэ ок, прост данных от сервера небыло, а сервер - клянётся мамой, что слал изо всех сил, и если сервер продуман, прикладывает tcp дампы.

Это тогда к реализации протокола.

Потому что если взять тот же http/s, то там есть поле Content-Length. Т.е., сервер и клиент оба знают сколько байт должно быть принято-передано. И, если что-то пошло не так, то клиент должен перезапросить данные и ему они должны вернуться в полном объёме. Если опять не вернулись, то опять перезапросить. В таком случае даже если промежуточный роутер профукает пару пакетов, то клиент будет точно знать что перезапрашивать надо. У него объём данных не сойдётся в сумме.

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

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

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

Это если не говорить про rpc например. Особенно с коллбэками, хотя и без колбэков всё так же только проблема будет только на стороне сервера.

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

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

Да.

Вот только для консервных банок (IoT в общем и целом) есть MQTT, который поверх tcp реализован и MQTT-SN (для sensor networks который), который может даже без TCP (по радиоканалу, тому же ZegBee) фигачить. Если по модели TCP/IP, то предполагается, что MQTT-SN будет работать в пространстве протоколов, основанных на UDP. Т.е., весь контроль за доставкой и целостностью на программисте. Но тут уже вопрос что выгоднее в каждом конкретном случае. Либо консервная банка имеет ресурсы для более «жадного» до ресурсов TCP, либо простецкий UDP, если есть абы какое сетевое соединение, а не голый радиоинтерфейс.