Леонид Каганов: дневник

Отпраздновали день рождения нашего друга Юры Ильина, снова разжигали шашлык дронами, уже тремя.

Из любопытных технических новинок: поизучали «умную лампу» Сяоми-Филипс (полное имя Xiaomi Mi Philips Eyecare Smart Lamp 2).

Это настольная лампа, очень милая вещь по доступной цене (около 3000 руб). Немного сложна в настройке: требуется поставить приложение Mi-home, в нем заводить аккаунт (если заведен — вспоминать пароль), но и потом ничего не заработает. И штрих-код с коробки для обнаружения устройства тоже не будет сканироваться. Тогда надо переставить в приложении регион на материковый Китай вместо России, приложение обрастет иероглифами, но работать с этого момента начнет. Видимо, погоня за Телеграмом заставила Роскомнадзор заблокировать и российские сервера Сяоми ;) Лампа управляется с приложения из любого места, в том числе можно давать доступ друзьям, чтоб они включали ее и регулировали яркость из Минска, например. Только не спрашивайте меня, для чего регулировать настольную лампу дистанционно через приложение. Это глобальная интеллектуальная проблема человечества, дело не в лампе — такова сама философия Умного Дома, бессмысленная и беспощадная. Разработчики соединили лампу и приложение просто потому что могут. Но у них нет для вас других идей, как это еще можно использовать. Гораздо интереснее, что у лампы внутри. Мы полезли:

Видно, что основное управление берет на себя банальный чип (вот мне подсказывает Паша) новой серии Атмела 32-битный Кортекc М0+ Акоммуникации обеспечиваются чипом WiFi. Мы с Пашей чуть было не поспорили на 100$, там ESP8266 или другое. Уже собирались сдуть термофеном металлические заглушки и посмотреть, но обратили внимание, как устройство получает IP в домашней сетке, и оказалось, что 10.8.0.172 представляется как ESP-0905CB (что-то типа этого, сегодня уже перестал рисовать свое имя в логах dhcp почему-то).

Но заинтересовало меня другое, и вот тут хотелось бы вашего совета. Лампа управляется через сервер Mi, в ждущем режиме там что-то мелко ходит:

# sudo tcpdump -n -vv -i br0 net 10.8.0.172

13:46:45.725152 IP (tos 0x0, ttl 255, id 495, offset 0, flags [none], proto UDP (17), length 60)    10.8.0.172.54321 > 120.131.15.130.8053: [udp sum ok] UDP, length 32
13:46:45.941787 IP (tos 0x0, ttl 47, id 61421, offset 0, flags [DF], proto UDP (17), length 60)    120.131.15.130.8053 > 10.8.0.172.54321: [udp sum ok] UDP, length 32

13:47:00.975581 IP (tos 0x0, ttl 255, id 496, offset 0, flags [none], proto UDP (17), length 60)    10.8.0.172.54321 > 120.131.15.130.8053: [udp sum ok] UDP, length 32
13:47:01.192115 IP (tos 0x0, ttl 47, id 3490, offset 0, flags [DF], proto UDP (17), length 60)    120.131.15.130.8053 > 10.8.0.172.54321: [udp sum ok] UDP, length 32

13:47:06.199815 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.8.0.172 tell 10.8.0.1, length 28
13:47:06.259667 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.8.0.172 is-at 78:11:dc:09:08:ce, length 28

13:47:16.238874 IP (tos 0x0, ttl 255, id 497, offset 0, flags [none], proto UDP (17), length 60)    10.8.0.172.54321 > 120.131.15.130.8053: [udp sum ok] UDP, length 32
13:47:16.455341 IP (tos 0x0, ttl 47, id 10340, offset 0, flags [DF], proto UDP (17), length 60)    120.131.15.130.8053 > 10.8.0.172.54321: [udp sum ok] UDP, length 32

13:47:31.510591 IP (tos 0x0, ttl 255, id 498, offset 0, flags [none], proto UDP (17), length 60)    10.8.0.172.54321 > 120.131.15.130.8053: [udp sum ok] UDP, length 32
13:47:31.727284 IP (tos 0x0, ttl 47, id 18016, offset 0, flags [DF], proto UDP (17), length 60)    120.131.15.130.8053 > 10.8.0.172.54321: [udp sum ok] UDP, length 32

13:47:36.729771 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.8.0.172 tell 10.8.0.1, length 28
13:47:36.777096 ARP, Ethernet (len 6), IPv4 (len 4), Reply 10.8.0.172 is-at 78:11:dc:09:08:ce, length 28

13:47:46.756520 IP (tos 0x0, ttl 255, id 499, offset 0, flags [none], proto UDP (17), length 60)    10.8.0.172.54321 > 120.131.15.130.8053: [udp sum ok] UDP, length 32
13:47:46.973216 IP (tos 0x0, ttl 47, id 24535, offset 0, flags [DF], proto UDP (17), length 60)    120.131.15.130.8053 > 10.8.0.172.54321: [udp sum ok] UDP, length 32

13:48:02.018330 IP (tos 0x0, ttl 255, id 500, offset 0, flags [none], proto UDP (17), length 60)    10.8.0.172.54321 > 120.131.15.130.8053: [udp sum ok] UDP, length 32
13:48:02.234890 IP (tos 0x0, ttl 47, id 32240, offset 0, flags [DF], proto UDP (17), length 60)    120.131.15.130.8053 > 10.8.0.172.54321: [udp sum ok] UDP, length 32
13:48:07.239761 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.8.0.172


_}

Если же на приложении (подключенном через другую сеть, например, мобильную) потыкать включение лампы, трафик усиливается:


<?php
13:54:02.774269 IP (tos 0x0, ttl 47, id 18602, offset 0, flags [DF], proto UDP (17), length 220)    120.131.15.130.8053 > 10.8.0.172.54321: [udp sum ok] UDP, length 192
13:54:02.895747 IP (tos 0x0, ttl 255, id 595, offset 0, flags [none], proto UDP (17), length 124)    10.8.0.172.54321 > 120.131.15.130.8053: [udp sum ok] UDP, length 96

13:54:05.413343 IP (tos 0x0, ttl 47, id 19911, offset 0, flags [DF], proto UDP (17), length 124)    120.131.15.130.8053 > 10.8.0.172.54321: [udp sum ok] UDP, length 96
13:54:05.513889 IP (tos 0x0, ttl 255, id 596, offset 0, flags [none], proto UDP (17), length 92)    10.8.0.172.54321 > 120.131.15.130.8053: [udp sum ok] UDP, length 64
13:54:05.518579 IP (tos 0x0, ttl 255, id 597, offset 0, flags [none], proto UDP (17), length 124)    10.8.0.172.54321 > 120.131.15.130.8053: [udp sum ok] UDP, length 96
13:54:05.735244 IP (tos 0x0, ttl 47, id 19986, offset 0, flags [DF], proto UDP (17), length 92)    120.131.15.130.8053 > 10.8.0.172.54321: [udp sum ok] UDP, length 64
13:54:05.829529 IP (tos 0x0, ttl 47, id 20019, offset 0, flags [DF], proto UDP (17), length 124)    120.131.15.130.8053 > 10.8.0.172.54321: [udp sum ok] UDP, length 96
13:54:05.915266 IP (tos 0x0, ttl 255, id 598, offset 0, flags [none], proto UDP (17), length 92)    10.8.0.172.54321 > 120.131.15.130.8053: [udp sum ok] UDP, length 64


Поскольку я плохо себе представляю, что означают эти строки и как работает UDP, то сформулирую вопрос так: мне при разработке своих девайсов тоже нужно, чтобы сервер что-то посылал девайсу. Сервер, понятное дело, открыт в сети и там можно установить любой софт, не только Nginx для веба. Девайсы обычно сидят где-то глубоко за NAT (чип WiFi или чип с симкартой), и не существует возможности залезть в настройки NAT и прописать какие-то переадресации портов для этих девайсов.

Мои девайсы, разумеется, умеют пингать сервер раз в две секунды по TCP/IP, спрашивая, нет ли новых команд. Но мне все-таки хочется добиться максимальной экономии трафика. В идеале — чтобы сервер сам мог прислать своему девайсу команду, это может случиться раз в час или неделю. Без всяких постоянных пингов. Но чтобы система не висла, не теряла соединение, а приняла эту команду. Для удобства понимания задачи представим, что мы сделали лампу на симкарте в роуминге, где порог тарификации 1мб, и он стоит 100$, а зажигать-тушить ее надо всего несколько раз в сутки ;)

Сердцем я чувствую, что это должно быть возможно. Умом понимаю, что такого пока в мире нет, если каждая такая лампа, пока горит, всё равно раз в пять секунд обменивается трафиком с сервером, хотя информации друг для друга у них нет. Что скажете? Есть ли примеры удачных реализаций, когда сервер способен быстро передать девайсу актуальную информацию по своей инициативе без вот такого регулярного обмана пакетами?

UPD: Спасибо всем, кто ответил. Вкратце: задача эта известная, считается болезненной и решения не имеет. В качестве костыля применяется пингование сервера с большой регулярностью (что мы наблюдаем и в лампе, и сам я в своих проектах это использую). Пинговать можно по TCP, чуть экономичнее по UDP, а можно держать открытым TCP-соединение, но его тоже придется часто пинговать и переустанавливать, иначе закроется. Ну в качестве надежд — фантазии и прогнозы, что в далеком будущем IPv4 разложился на плесень и на липовый мед, все перейдут на IPv6, и тогда этой проблемы не будет. Но это мы слышим последние 20 лет, из них последние 15 понимаем, что оно никогда не случится ;)