Вы всё неправильно сделали!
Надо было взять б/у сервер на али-экспресс, с двумя 12-ядерными процессорами и 64 гигами оперативы. и в НЕГО воткнуть USB-свисток термометр.
мне кажется, вы как-то через-чур преувеличиваете сложность СИ, не так страшен чёрт как его малюют. пишете некое CORE (ядро) для общей обработки Websockets, а для разных функций — разные подключаемые DLL модули. и не придётся перекомпилять всё то и дело.
а вообще, я уверен, что-то уже есть. вот люди советуют вам посмотреть libwebsocket и libevent, посмотрите, хотябы и обзорно. хотябы и после того, как «горящий» проект сдадите в прод. я думаю такие вещи имеют высокую повторяемость в потребности, и время на изучение, проработку вопроса не будет потрачено без пользы. оно себя с лихвой окупит в будущем.
не холивара ради, простое любопытство: почему не СИ?
я набросал работающий фреймворк за день. но у меня уже было понимание, как устроен протокол. разобрался когда пытался, несколько лет назад, делать сервер на CLI PHP.
<зануда> "террабайт" — да, чувствуется 9 классный бекграунд )))</зануда>
у самого тоже 9 классов. но два года работы верстальщиком газеты сделали своё дело, правильно говорят "читайте больше" и грамотность сама придёт.
конечно, в реальном ПО ответы парсятся, и как минимум проверяется код ответа.
я в примерах только в одном месте поставил наспех написанный, максимально кратко, пример как проверять ответы «parse answer JSON (lame)». очень не хотелось раздувать код.
по себе знаю, как тяжело читать чужие сорцы, когда суть разбавлена всякой мишурой эксепшенов и прочего. я же тут не выпендриваться пришёл, какие крутые у меня парсеры и обработчики исключений. я был бы благодарен всем кто пишет примеры, если бы они тоже старались акцентировать внимание в примерах максимально на сути.
ну и да, я не старался написать прям уж исчерпывающий мануал, со всеми нюансами и аспектами. те кто уловят суть, думаю без труда и разработают вопрос, до той степени как им надо.
да, я тоже оочень сильно сомневаюсь в этих утверждениях, про свои методы фоновой связи у фейсбуков, без рутов, без гапсов. но спорить не стал, так как достоверно не знаю.
да, про Wireshark это такая шутка конечно ) я хотел сказать, что пользовался снифферами до появления Wireshark'а )
статься уже в архиве, никто в такие дебри не будет заходить и читать каменты. теперь только ищущие по теме (для кого я собственно её и писал) будут её находить и читать. хипсторы на гироскутерах слава богу уехали.
яж присылал про UDP hole punching. я разрабатываю под сетевые протоколы. и если не ошибаюсь, IP адрес в паре с портом называется сокетом, и используется натом, чтоб понять кому дальше слать пакет (когда он пришёл как входящий).
также я писал про то, что нат может преждевременно закрыть активный сокет, если по нему слишком долго не будут ходить пакеты. поэтому, чтоб он не закрывался, гоняют пустые пакеты, keepalive.
я посмотрел ваш профиль. верю, что разбираетесь в сетях. но и мне доводилось писать сетевые драйверы на микроконтроллеры. о протоколах MAC, IP, TCP, UDP и ICMP знаю не по наслышке. Wireshark'ом пользовался, когда его ещё не было )) была под 98-ми виндами прога Commview.
ох, теперь я понимаю, что надо было ЯВНО написать, что такой способ актуален ТОЛЬКО если вы планируете прикрутить уведомления к своему УЖЕ существующему приложению. это сняло бы половину комментариев с недоумениями.
да, вот хотел написать… push оно только с маркетинговой точки зрения, это абстракция. на техническом уровне это pull.
гугл ещё на ранних этапах понял, что каждое второе приложение будет создавать коннект со своим сервером, и вся эта вакханалия будет жрать батарею и сокеты. и решили всё это дело объединить в единую точку входа, и интегрировали её в GAPS. и получается, да, именно гапс определяет с какой частотой ходить на сервера, и чекать что там новенького.
с GPS такая же петрушка. тоже как-то писал приложение с GPS, много интересных поведений начитал. там тоже все попытки душить в фоне GPS мотивировали жёром батарейки.
источников не припомню уже.
и у WiFi и модема очень разные стратегии по энергопотреблению. замечал, что на планшет, после перевода в спящий режим я еще могу заходить несколько секунд, около 20. потом рубит. но это планшет на Win10, на андроиде вероятно по другому. яж говорю, все эти стратегии, когда отрубать питалово с модемов и сетевух, отданы на откуп вендорам, и они сами, на своё усмотрение их реализуют, единого стандарта нет.
даже могут менять в версиях прошивок. отсюда и отзывы пользователей «новая прошивка жрёт батарею!!1». это не прошивка жрёт, а сетевуха стала реже отключаться.
думаю, проверить сетевым анализатором это будет самый верный и быстрый способ. я только знаю, что гугл рекомендует настраивать фаерволы на порт 5228 (дополнительно 5229 и 5230), чтоб не блокировали их на исходящий. (например)
сервер не устанавливает соединение со смартфоном по своей инициативе. он только ждёт, когда смарт САМ того пожелает, установит соединение с ним, обменяется данными и закроет соединение. так работает пуш.
я на фразе «пробить NAT» подумал, что вы имеете в виду p2p соединение, ошибся.
а для соединения nat-to-real никакие хитрости и не нужны. достаточно поддерживать соединение отправкой пустых keepalive пакетов по UDP, чтоб всякие промежуточные прокси не посчитали соединение покинутым и не перестали его обслуживать.
а в таких вещах как push, постоянное соединение поддерживать невыгодно с точки зрения батареи. поэтому там реализовано так:
— клиент подключается к серверу
— отправляет свои (скопившиеся) сообщения на сервер
— принимает с сервера скопившиеся сообщения
— отсоединяется от сервера
— снимает питание с сетевухи (модема), чтоб по человечески поспать
поэтому на спящий смартфон сообщения не приходят мгновенно, а только когда смарт просыпается, и чекает сервак. и эти интервалы разные, в зависимости от предпочтений ОС по энергосбережению.
я читал, ещё несколько лет назад, про стратегии поддержки соединений в спящем режиме. как сейчас дела обстоят не знаю. но если в общих чертах, то система подкапливает данные для отправки, периодически поднимает модем, скажем раз в минуту, и после обмена опять его усыпляет.
я подозреваю, что сетевой стёк скрыт от простых смертных приложений, на пользовательском уровне. и доступен только привелегированным, а им вероятно нужен рут. но это всё мои догадки, не проверял реально, как обстоят дела.
если интересно, для nat-to-nat соединений прекрасно работает en.wikipedia.org/wiki/UDP_hole_punching. да, понадобится всё-таки сервер посредник, но исключительно для обмена адресами и портами.
Надо было взять б/у сервер на али-экспресс, с двумя 12-ядерными процессорами и 64 гигами оперативы. и в НЕГО воткнуть USB-свисток термометр.
а вообще, я уверен, что-то уже есть. вот люди советуют вам посмотреть libwebsocket и libevent, посмотрите, хотябы и обзорно. хотябы и после того, как «горящий» проект сдадите в прод. я думаю такие вещи имеют высокую повторяемость в потребности, и время на изучение, проработку вопроса не будет потрачено без пользы. оно себя с лихвой окупит в будущем.
не холивара ради, простое любопытство: почему не СИ?
я набросал работающий фреймворк за день. но у меня уже было понимание, как устроен протокол. разобрался когда пытался, несколько лет назад, делать сервер на CLI PHP.
<зануда> "террабайт" — да, чувствуется 9 классный бекграунд )))</зануда>
у самого тоже 9 классов. но два года работы верстальщиком газеты сделали своё дело, правильно говорят "читайте больше" и грамотность сама придёт.
"можно выбрать папку установки!"
самый оригинальное место установки винды, которое доводилось видеть C:/Games/Muzdie/
следующими видимо будут фемтосервисы.
я в примерах только в одном месте поставил наспех написанный, максимально кратко, пример как проверять ответы «parse answer JSON (lame)». очень не хотелось раздувать код.
по себе знаю, как тяжело читать чужие сорцы, когда суть разбавлена всякой мишурой эксепшенов и прочего. я же тут не выпендриваться пришёл, какие крутые у меня парсеры и обработчики исключений. я был бы благодарен всем кто пишет примеры, если бы они тоже старались акцентировать внимание в примерах максимально на сути.
ну и да, я не старался написать прям уж исчерпывающий мануал, со всеми нюансами и аспектами. те кто уловят суть, думаю без труда и разработают вопрос, до той степени как им надо.
статься уже в архиве, никто в такие дебри не будет заходить и читать каменты. теперь только ищущие по теме (для кого я собственно её и писал) будут её находить и читать. хипсторы на гироскутерах слава богу уехали.
также я писал про то, что нат может преждевременно закрыть активный сокет, если по нему слишком долго не будут ходить пакеты. поэтому, чтоб он не закрывался, гоняют пустые пакеты, keepalive.
я посмотрел ваш профиль. верю, что разбираетесь в сетях. но и мне доводилось писать сетевые драйверы на микроконтроллеры. о протоколах MAC, IP, TCP, UDP и ICMP знаю не по наслышке. Wireshark'ом пользовался, когда его ещё не было )) была под 98-ми виндами прога Commview.
ох, теперь я понимаю, что надо было ЯВНО написать, что такой способ актуален ТОЛЬКО если вы планируете прикрутить уведомления к своему УЖЕ существующему приложению. это сняло бы половину комментариев с недоумениями.
нынче это не так, сотовые операторы в большинстве случаев даже серого IP не дают. натят.
гугл ещё на ранних этапах понял, что каждое второе приложение будет создавать коннект со своим сервером, и вся эта вакханалия будет жрать батарею и сокеты. и решили всё это дело объединить в единую точку входа, и интегрировали её в GAPS. и получается, да, именно гапс определяет с какой частотой ходить на сервера, и чекать что там новенького.
с GPS такая же петрушка. тоже как-то писал приложение с GPS, много интересных поведений начитал. там тоже все попытки душить в фоне GPS мотивировали жёром батарейки.
и у WiFi и модема очень разные стратегии по энергопотреблению. замечал, что на планшет, после перевода в спящий режим я еще могу заходить несколько секунд, около 20. потом рубит. но это планшет на Win10, на андроиде вероятно по другому. яж говорю, все эти стратегии, когда отрубать питалово с модемов и сетевух, отданы на откуп вендорам, и они сами, на своё усмотрение их реализуют, единого стандарта нет.
даже могут менять в версиях прошивок. отсюда и отзывы пользователей «новая прошивка жрёт батарею!!1». это не прошивка жрёт, а сетевуха стала реже отключаться.
думаю, проверить сетевым анализатором это будет самый верный и быстрый способ. я только знаю, что гугл рекомендует настраивать фаерволы на порт 5228 (дополнительно 5229 и 5230), чтоб не блокировали их на исходящий. (например)
а для соединения nat-to-real никакие хитрости и не нужны. достаточно поддерживать соединение отправкой пустых keepalive пакетов по UDP, чтоб всякие промежуточные прокси не посчитали соединение покинутым и не перестали его обслуживать.
а в таких вещах как push, постоянное соединение поддерживать невыгодно с точки зрения батареи. поэтому там реализовано так:
— клиент подключается к серверу
— отправляет свои (скопившиеся) сообщения на сервер
— принимает с сервера скопившиеся сообщения
— отсоединяется от сервера
— снимает питание с сетевухи (модема), чтоб по человечески поспать
поэтому на спящий смартфон сообщения не приходят мгновенно, а только когда смарт просыпается, и чекает сервак. и эти интервалы разные, в зависимости от предпочтений ОС по энергосбережению.
если интересно, для nat-to-nat соединений прекрасно работает en.wikipedia.org/wiki/UDP_hole_punching. да, понадобится всё-таки сервер посредник, но исключительно для обмена адресами и портами.