@witadol17 янв 2017 в 06:32

Автопоиск IP-адресов

4 мин

17K

Python *

Из песочницы

Recovery Mode

Комментарии 20

@miksoft 17 янв 2017 в 08:37

сервер, в моем случае, — это всего лишь десктопное приложение, которое пользователь может запускать на любом компьютере в подсети

А как часто реально будет изменяться этот «любой» компьютер?

@witadol 17 янв 2017 в 09:26

Ну это уже зависит не от меня, а от обслуживающего персонала, у меня же стояла задача максимально упростить им жизнь

@avallac 17 янв 2017 в 09:43

Шел 2017 год… А велосипедостроительство только набирало обороты.

Не понятна проблема в принципе, если все оборудование все хе находиться в одном бродкаст домене, то что мешает использовать статичный IP для сервера-ноутбука. Если это все ходит через интернет, то без специальной настройки всех промежуточных маршрутизаторов udp broadcast не пойдет через них. Вообще решение выглядит как UDP чаты из 90ых.

Если это распределенная сеть, то без выделенного сервера ну никак. Как вариант взять нормальное решение для автодеплоя, например тот же SaltStack и делать со своими киосками любое непотребство в любое время.

@Sly_tom_cat 17 янв 2017 в 11:23

Ну как учебная задачка — вполне себе.
Или другими словами: Не построив велосипеда самолета не сделаешь.

@kozzztik 17 янв 2017 в 12:12

Если уж делать учебную задачку, тогда лучше сразу на asyncio — это было бы познавательней.

@bak 17 янв 2017 в 10:31

Про DNS автор видимо не слышал?

@witadol 17 янв 2017 в 11:26

Слышал краем уха =), но ездить и настраивать по всем магазинам DNS-серверы, мне как-то не сильно хотелось, а мое решение не требует никаких дополнительных телодвижений со стороны админов

@hombit 17 янв 2017 в 12:11

Почему бы не использовать какое-нибудь готовое решение для обнаружения сервисов? В Википедии вот целый список есть

@Eugene_Burachevskiy 17 янв 2017 в 13:12

Интересное решение, похожее на dhcp. Но использование отдельного коммуникационного сервера, куда все терминалы отсылают свои айпишники и откуда администратор их забирает (или даже куда администратор кладет обновление базы, а терминалы это обновление скачивают сами) выглядит как-то логичнее и снимает ограничение на нахождение админа и терминалов в одной подсети.

@xcore78 17 янв 2017 в 14:10

Можно было бы зашить в терминалы IP-адрес сервера обновлений, но так как сервер, в моем случае, — это всего лишь десктопное приложение, которое пользователь может запускать на любом компьютере в подсети, то такое решение тоже не подошло.

Подошло бы, если бы вы знали про маршрутизацию.

@sakutylev 17 янв 2017 в 15:59

А не нужно ли первую функцию обернуть декоратором менеджера контекста, коли вы к ней так обращайтесь?

@witadol 17 янв 2017 в 19:20

Да вроде как для 3-го питона в сокетах уже реализован контекстный менеджер, но вопрос хороший, я прям покапался в гугле и понял, что я не до конца понимал принцип работы контекстных менеджеров. Думал, что их можно вызывать на любом объекте, у которого есть метод close() =)

@pero1 17 янв 2017 в 16:17

поки входжу в цю тему. Цікаво а чому не використати papput для вирішення цієї задачі не підходить?

@DjPhoeniX 18 янв 2017 в 00:03

Если уж действо происходит в локальной сети, чем же ARP не угодил? Или ICMP на худой конец? Определяем всех «живчиков» в радиусе досягаемости, при необходимости фильтруем по MAC, а дальше по какому-нибудь SSH или FTP (желательно за SSL) заливаем обновления.

@witadol 18 янв 2017 в 11:37

И что бы мне дал ARP? Насколько я знаю, он нужен чтобы выяснить MAC по уже известному IP, мне же нужно было узнать IP.

@DjPhoeniX 22 янв 2017 в 19:55

Насколько я знаю, он нужен чтобы выяснить MAC по уже известному IP

Не только:

$ arp -i en0 -l -a -n
Neighbor                Linklayer Address Expire(O) Expire(I)    Netif Refs Prbs
192.168.97.1            f4:6:69:17:85:a9  2m53s     2m53s          en0    1
192.168.97.37           28:e1:4c:d2:59:e9 expired   expired        en0    1
192.168.97.40           24:a:c4:3:ed:80   2m4s      2m4s           en0    1
192.168.97.42           54:27:1e:d:73:81  1m37s     1m37s          en0    1
...

@vanyas 18 янв 2017 в 02:51

Если всё в одном бродкаст домене, а не в интернете, то в чём проблема выдать статический ip серверу?
Ну а бродкаст 255.255.255.255 вообще убил, почему было не юзать хотя бы мультикаст? Зачем этот бродкаст флуд по всей сети? Благо в ipv6 бродкаст убили как класс.

@DjPhoeniX 18 янв 2017 в 03:19

Ну вот с мультикастом не соглашусь. Сам нарвался на то, что 146% оборудования умеет его чуть хуже чем отвратительно. Соглашусь с плохой идеей про 255.255.255.255 — их тоже половина роутеров зарезает (и правильно, ибо нехрен) — local-broadcast (192.168.x.255) тут будет решением более близким к «сойдёт». Но всё-таки оптимальный вариант — ARP.

@vanyas 18 янв 2017 в 22:27

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

@Dr_Wut 23 янв 2017 в 13:08

Мда… Вот реально, а почему не сделали полноценную клиент-серверную платформу? Зачем эти велосипеды?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий