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

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

Из любопытных технических новинок: поизучали «умную лампу» Сяоми-Филипс (полное имя 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, в ждущем режиме там что-то мелко ходит:

<?php# sudo tcpdump -n -vv -i br0 net 10.8.0.17213: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 понимаем, что оно никогда не случится ;)