Связь ПК-смартфон в своей программе по Wi-Fi

KDE connect?

Я держал его в уме, пока писал это. :) Но это ведь не протокол и не API, это конкретная пара программ?

Или они предлагают и API, которым можно такое сделать, не прибиваясь к кедам?

Да, я знаю, что у них есть сборки под разные ОС, но я с точки зрения программиста спрашиваю. Как сделать такое в СВОЕЙ программе…

Каждый лепит свои костыли.

Хм, а над чем он их лепит? Ну вот (для начала) просто тупо найти кандидаты в парные устройства по вайфаю. Broadcast-запрос, что ли, по подсетке рассылает?

Как только один пример того, что делают люди, чтобы не работать на BSD sockets (а это бывает неприятно), ZeroMQ + zbeacon для поиска друг друга в локальной сети.

Но бывают Wi-Fi сети, которые запрещают клиентам говорить друг с другом. (Пример: XXX платит соседу половину стоимости интернета и пользуется «гостевой» сетью, где эта галочка стоит по умолчанию.) Там только через «облако» авторов приложения, со всеми вытекающими.

Ну, исходный код всех приложений открыт, я это имел ввиду. Наверно можно глянуть в сорцах, что они там придумали

Для IPv4 броадкаст, для IPv6 мультикаст. https://stackoverflow.com/questions/64030969/how-to-broadcast-a-udp-packet-from-android

что делают люди, чтобы не работать на BSD sockets

А чем в этом случае могут помочь BSD sockets?

Там только через «облако» авторов приложения, со всеми вытекающими.

Ну если всё совсем плохо — можно ещё сделать эталонную реализацию такого «облака» и предоставить всем желающим возможность ставить её на свой сервер. Но это уже матан, с простыми бы случаями разобраться…

Да, тот же MyPhoneExplorer работает не идеально, жалобы на невяжущийся Wi-Fi у людей бывают. Но — как-то работает.

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

RPC (или даже gRPC), distributed applications, web services, message oriented middleware, MQ, p2p (это больше для обзора «чо вообще есть»), ну и «REST хватит всем». Отдельностоячие рукопашные броадкасты с мультикастами тебе не нужны, это умеют чаще всего уже какие-нибудь самоклеящиеся миддлвари (особенно всякие MQ с гарантированной доставкой, брокерами и туннелированием сквозь NATы), т.к. низкоуровнево слишком для именно приложений, если только ты не хочешь в процессе написать «глючный и частичный» велосипед с квадратными колесами, т.е. самопальный RPC, подпертый костылями.

А чем в этом случае могут помочь BSD sockets?

ну, чем-чем, понадувать щоки на лоре :)

Так вот. Интересует сам процесс поиска и «снюхивания», как можно реализовать это в своей программе.

Сервер шлет пакеты на broadcast, клиенты слушают на определённом порту и отвечают на discovery пакет или сразу на ip сервака коннектятся.

Так вот. Интересует сам процесс поиска и «снюхивания», как можно реализовать это в своей программе.

Общий принцип любого такого механизма это какой-то общий известный всем участникам ресурс — либо общий IP адрес куда покричать «эй, есь кто?!» и порт на послушать анонсы, либо имя внешнего сервака, на который можно заслать депешу «здесь был Вася, а вообще он вон там», подписаться на рассылку адресной книги, который сервак поработает сводней, разошлет 5-100505 друзьям, а они уже сами-сами, или прямо перезвонит в случае «захода в чят» других «со-участников».

А чем в этом случае могут помочь BSD sockets?

Имею в виду, через них в итоге всё и работает, но вручную написать под них правильный код довольно сложно. (Особенно интересно писать код одновременно под них и под WinSock2.)

Соседей по Wi-Fi сети, например, можно искать при помощи SOCK_DGRAM и SO_BROADCAST, но пользоваться обёртками над сокетами, которые предоставляют абстракции, гораздо удобнее, а результат наверняка будет более надёжным.

какой-то общий известный всем участникам ресурс

В случае MyPhoneExplorer такого, если не ошибаюсь, нет. На телефоне запускается клиент, на ПК - сама программа, на телефоне устанавливается Wi-Fi PIN, ПК находит телефон и этот PIN запрашивает. Надо для чистоты эксперимента роутер из интернета выдернуть и посмотреть, будет ли работать. :)

P.S. Авторы уверяют, что

In opposite to many other solutions MyPhoneExplorer does work complete locally without using any third-party server!

Программа проприетарная. Как там… «Джентльменам в нашем клубе принято верить на слово». :)

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

Ошибаешься :) Т.к. из ничего ничего не будет. Точка рандеву у них какая-то своя есть, либо они используют существующие механизмы сетевого стека (их еще и несколько может быть по разным механизмам, в случае этого приложения нужно или сорцы посмотреть или поснифать трафик :)). При желании ты можешь сам все написать в виде альтернативного ARP или на уровне существующего, но вряд ли ты захочешь, т.к. есть обертки, которые это уже реализуют и спускаться настолько вниз от прикладного уровня не нужно :) Т.е. для написания приложений самому в общем-то не обязательно даже ICMP/IGMP трогать — хотя понимать нужно.

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

Это все слоптимизация, если уж прям в деталях низкоуровнево разобраться хочется — читай сразу RFC про WiFi :) Если приложение написать распределенное — попробуй для начала связать две проги через опенсорнсные MQ или просто сделай ldd kdeconnect'у и используй то же самое :) Главное определиться — хочется приложения писать или p2p фреймворки :) Потому что в процессе упарывания на уровне ARP/IGMP ты фреймворк и напишешь.

Возможно этот коммент окажется самым бесполезным в треде, но все ж.

Во flac player на яблофоне очень простая синхронизация – на телефоне запускается легонькая http-морда и сервер. Соответственно с любого устройства через браузер можно зайти и перекинуть нужные треки. В детали реализации не вникал, но подозреваю что все не очень сложно. Может такой вариант пригодится, хотя бы как отладочно-девелоперский?

Соответственно с любого устройства через браузер можно зайти

То есть опять-таки надо знать IP, куда заходить?

Плеер показывает текущий ип и порт, на котором запущена морда.

Его так или иначе надо как-то узнать :) Либо не его — тогда MAC. А это за пределами локалки не очень хорошо работает :)

Эксплорер от ASUS позволяет делать то же самое, когда по SMB почему-то нельзя ничего найти — всегда есть браузер :)

Или они предлагают и API, которым можно такое сделать, не прибиваясь к кедам?

Есть же GSConnect.

Там используются банальные http(s) запросы, да поиск компов в сети по Avahi.

У Kodi точно такой же механизм удалённого управления - http(s) запросы.

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

Как говорится, вместо тысячи слов:

https://0x0.st/oHGZ.PNG

slackwarrior я больше про то что сам не настоящий сварщик, рассуждаю как домохозяйка, коей и являюсь. :)

Да я-то понимаю про что ты :) ТСу хочется механизмов сетевого discovery, но это надо просто идти и читать. И определиться, приложения связывать или устройства (на самом деле это монопенисуально, но разница лишь на каком уровне организовывать это все — для приложений что-то ниже HTTP скорее всего давно уже оверкил, если конечно не хочется переизобретать механизмы надежности и лично трахаться с туннелями сквозь NATы). В одноранговых сетях либо есть диспетчер к которому все ходят (и механизм его выбора среди пиров, если он явно не назначен), либо групповые адреса с портами, где происходит перекличка. В любом случае никакой магии — либо адрес и порт известны заранее, либо узнаются по эху запросов «Эй, есь кто?» в IGMP. И это все уже завернуто в имеющихся RPC, где обычно слабо колыхает в какой именно среде это все происходит.

Но бывают Wi-Fi сети, которые запрещают клиентам говорить друг с другом. (Пример: XXX платит соседу половину стоимости интернета и пользуется «гостевой» сетью, где эта галочка стоит по умолчанию.) Там только через «облако» авторов приложения, со всеми вытекающими.

Можно же по bluetooth, не хватает этого в kdeconnect

Твои клиент и сервер уже зацеплены за сеть с одним SSID (да хоть бы и разными SSID) или ты действительно хочешь изобрести пони на гусеничном ходу поверх 802.11?

Предположим, зацеплены. И..?

Если зацеплены, то «по Wi-Fi» – нерелевантная часть и вопрос сводится к «как двум IP-хостам найти друг друга в широковещательном домене».
В простейшем варианте сервер слушает бродкасты с условленным содержимым, а клиент их шлёт – строк по десять на питоне. «Каждому!» (с).

Ну или если надо, чтобы было о чём в резюме писать: avahi, MQ, gRPC, protobuf, mongodb is webscale, DDD, event-driven, cloud native и прочее.

Broadcast-запрос, что ли, по подсетке рассылает?

А чем Вас смущает такой подход? Имхо, вполне удобный вариант.

По факту у нас получаются два устройства, которые не знают адреса друг друга. Для того чтобы они смогли начать общаться, им необходимо эту неизвестность ликвидировать. По большому счёту видится только два варианта:

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

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

ws-discovery. Через него например ip камеры в сети ищут.

Некоторые разработчики делают пары программ ПК-Андроид, и учат их синхронизироваться по Wi-Fi.

Если имеется в виду создавать вайфай точку на телефоне, и туда конектить ПК, то это извращение. Если же имеется в виду использовать ЛВС, то причем тут вайфай?

Вообще для программы должно быть монопенисуально какой вид связи используется, вайфай, провод или же впн, иначе будут проблемы типа - я тут включил УСБ сетевуху, а программа не работает или у меня впн и оба устройства друг друга видят, а программа не работает. Последний случай я прочувствовал на себе, хотел распечатать на домашнем принтере, а хпшный софт не увидел принтера за впн, пришлось поднимать cups и уже через него печатать.

Предположим, зацеплены. И..?

Ты думаешь что там какой-то другой tcp/ip? Нет никакой разницы, wifi или провод. Тред удивил, комментарии тоже.

Дьявол кроется в деталях. Когда адреса уже известны — да, принципиальной разницы нет. Впрочем, несколько направлений мне уже подсказали.