Как реализован коннект мессенджеров и работа сети?
Несколько вопросов - по программированию в android и глобально по сетям. Сразу хочу обратить внимание, что я не программист (но есть определенные знания), скорее продвинутый пользователь.
Вопрос 1-й. У меня установлено 4-ре мессенжера - viber, hangouts, watsapp, skype. Все они довольно шустро (по сравнению с десктопными версиями) откликаются на входящие сообщения. Задержка секунд 5-10 по сравнению с десктопом даже если телефон "спит". А иногда сообщения приходят и быстрее чем на десктоп.
Вопрос - как это реализовано?
Если допустить что я за NAT, или еду в машине и постоянно меняю базовую станцию (возможно и ip), то, следовательно инициатором соединения с сервером сообщений должен быть я (точнее мой телефон). Допускаю, что при определенном событии (отключение/подключение к точке wifi, смене cellId) android сообщает зарегистрированным слушателям (мессенжерам), что допустим ip изменился, и надо сообщить своим серверам новые данные для коннекта. После чего все (viber, hangouts, watsapp, skype) дружно ломятся к "родительским" серверам и сообщают - "Мы здесь".
Но что происходит в спящем режиме? Допустим сервер skype получил входящее мне сообщение. Куда он коннектится? Обычно, насколько я знаю, что бы установить коннект с другим компьютером в сети нужен ip и порт. Причем порт должен постоянно прослушиваться каким то процессом. Причем насколько я понимаю - одним. Но если я за NAT и никакой порт не проброшен? По идее тогда сервер skype должен ждать, пока мой клиент не проснется, сделает запрос и только тогда он сможет ему сказать - "парень, у тебя тут сообщение". Следовательно мой клиент-скайп должен периодически - скажем раз в 30 сек делать запрос? Но тогда нужно ли ему будить мой телефон (выводить из спящего режима)?
По моим ощущениям телефон с включенным skype ест не намного больше батарею, чем с отключенным. Если быть справедливым - то я практически не вижу разницы. При этом никакой активностью ночью (судя по данным androida - расход батареи). Но сообщения входящие - доходят.
В общем, интересен принцип работы.
Так же допускаю (предполагаю/фантазирую), что в android может быть какая то единая служба входящих сообщений (которая может работать условно говоря - аппаратно в спящем режиме). И которая при получении входящего - будит нужный процесс. За счет чего и получается, что основные наши процессы спят и будит разбужены извне только по событию (приход сообщения)
Из первого вопроса вытекает второй.
Допустим я за NAT. Посылаю запрос на сервер (сервер естественно с белым ip и открытым портом). Сервер мне отвечает. Причем понятно отвечает не мгновенно - допустим ему нужно время на обработку запроса. Какой время продержится этот условно говоря "канал". Это зависит от моего роутера? В нем же, как я понимаю, хранится таблица NAT (которая, как я понял временно хранит соответствие внутреннего ip и порта отправленного наружу пакета (с определенного, свободного порта роутера), что бы потом, при ответе внешнего сервера на этот порт переадресовать его на внутренний ip).
Так вот - сколько времени будет "жить" этот канал? Для домашних роутеров например. Секунд 30 предполагаю точно, а больше 5 минут? Час? Сутки? От чего это зависит?
Попытайтесь сформулировать ваши вопросы короче с меньшем количеством воды.
Я вижу как-то так:
1) Как на Андроид приходят уведомления в спящем режиме?
2) Как мессенджеры работают за NAT?
Это ваши вопросы?
на мобильных это чаще реализовано на push уведомлениях, поэтому быстро, на десктопе никах ограничений нет, и nat не помеха, поэтому тут вопрос чисто архитектурный "так сделали"
Про спящий режим. Вопрос вытекает из ответа - если сообщения доходят, значит спит только частично.
С NAT всё сложнее. Тут 2 части:
1) Обычным сообщениям NAT не помеха. Они идут через сервер. Обычное TCP соединение к серверу с keep alive.
2) Со звонками всё сложнее, во-первых звонки идут напрямую между юзерами и используется уже UDP протокол. Технология которую использует скайп(да и наверное другие мессенджеры) схожа со STUN(https://en.wikipedia.org/wiki/STUN).
Как вариант UDP hole punching (http://en.wikipedia.org/wiki/UDP%5Fhole%5Fpunching)
Простой
