throughtheether

phantomjs или selenium

Selenium же

Я изучал эту тему долго и мучительно (начав путь примерно с такого же вопроса, что и вы), но не являюсь профессионалом. Буду рад замечаниям и критике.

Вкратце - проблемы, описанные в теле вопроса не соотносятся с заголовком и направлением копания в сторону, мягко говоря, неоднозначного и замыленного термина "роуминг". Для быстрого понимания темы лучше временно выкинуть это слово из вокабуляра. Заметьте, кстати, что в серьезных статьях пишут как минимум fast roaming, а не просто roaming или seamless roaming.

Также есть две спорные препозиции, начну с них.
1.

Единая Wi-Fi сеть

Если у вас WPA2-PSK, и если не рассматривать малоприменимую в нашей жизни экзотику вроде одного MAC-адреса на разных ТД и mesh-сетей разных уровней, то у вас и так "единая" Wi-Fi сеть. Не менее единая чем у очень богатых дядей с Cisco и Juniper, и менее богатых с D-Link и Ubiquiti. Это я к тому, что нет никакой серебряной пули, решающей описанные вами проблемы. Группа ТД с любой фичей, описание которой содержит слово "роуминг", всё равно останется группой ТД.

2.

Есть решения от тех же D-Link или Ubiquiti, которое позволит решить данную проблему.

PMKID caching - то, что вендоры раньше называли бесшовным роумингом (более честно - zero handoff у Ubiquiti), решает другую проблему - долгую аутентификацию "с нуля" при переключении клиента на другую ТД, в случае, если используется не PSK (там такой проблемы нет), а EAP метод аутентификации. С помощью кэширования части ключа и доступа к кэшу со всех ТД. При этом, в таком решении может не быть 802.11k/802.11r.

3. 802.11k/802.11r возможно уже есть в OpenWRT (точнее, hostapd), но это нам не сильно поможет. Во-первых, нет внятного описания того, какое железо для этого нужно, нет инструкций как это настраивается, непонятно даже - нужно ли это настраивать. Во-вторых, всё равно на рынке очень мало беспроводных клиентов, поддерживающих 802.11k/802.11r. В-третьих, не факт что если всё это взлетит - будет много толку.

4. Дело в том, что за исключением специальных редких дорогих vendor-locked беспроводных клиентов, добровольно решение о смене ТД всегда принимает клиент, а не ТД или некий контроллер. ТД может только в рекомендательном порядке рассказать клиенту о своих соседях в рамках 802.11k.

5. Насколько я понял, 802.11r - это продвинутая стандартизованная версия PMKID caching, которая ускоряет процесс аутентификации при переходе на другую ТД. Никакой связи с функцией поиска ТД с лучшим сигналом.

6. Специально написанные для ТД скрипты (иногда облаченные в красивые макретинговые словеса) могут разово деассоциировать (кикать) из своей сети клиента (плюс иногда еще блокировать подключение на период времени) при преодолении порога качества сигнала. Всё это - в надежде, что клиент одумается и подключится к соседу с лучшим сигналом. ТД не знает что творится "в голове" клиента, поэтому нет никаких гарантий, что клиент, к примеру, сначала поищет лучшую ТД во всех диапазонах, а не подключится к еще более дальней ТД в том же канале. В стандартах это не описано, ни о какой предсказуемости и бесшовности тут речи не идет, но наверное в некоторых случаях игры с такими скриптами могут помочь убить время.

7.

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

В итоге, возможно когда-то чем-то сможет помочь 802.11k, а решение описанной проблемы скорее найдется в банальных действиях:

• переводе всего, что переводится на кабель
• переводе части того, что переводится на 5GHz
• изменение конфигурации ТД в пространстве
• изменение частотной конфигурации ТД
• изменение мощности ТД (скорее в сторону понижения, чем повышения)
• изменение количества ТД (не факт, что в сторону увеличения)
• и т.д.

P.S.: Про контроллеры. Насколько я в этом разобрался, все эти вендорские беспроводные контроллеры не нужно воспринимать как нечто уникальное, добавляющее сверх-фичи недоступные простым смертным. Обычно это просто набор программных сервисов, вынесенных из точек доступа для солидности, избыточности и удобства (единая точка управления, PoE и т.д.). Грубо говоря, это коробка, где помимо очевидных вещей могут быть: проприетарный протокол массового распространения настроек, кэш PMKID или аналога, RADIUS или аналог, совсем банальные DHCP, BOOTP, TFTP и т.д., скрытые под толстым слоем красивых названий.

Еще по теме:
Сначала указанную ветку комментариев, потом статью., чтобы была верная поправка на ветер "вендорства".
В основном про аутентификацию и её ускорение.
Пример внятной подачи информации от производителя клиентских устройств.

Netflow используется для анализа трафика который был передан от одного устройства другому, сами данные в нем не учитываются. Для анализа самого трафика проходящего через роутер надо зеркалировать трафик см. www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_usr_...

imho если есть возможность сделать это на коммутаторе (через span), лучше делать на нем.

Что именно вы хотите вытащить из пакета?
Netflow позволяет получать

• Source and destination IP address
• Input and output interface number
• Source and destination port number
• Layer 4 Protocol
• Number of packets in the flow
• Total Bytes in the flow
• Time stamp in the flow
• Source and destination AS
• TCP_Flag & TOS

Скорее всего вам нужно смотреть на настройку Port Monitoring (SPAN) на Cisco и соответственно софт, который сможет с ним работать.

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

https://docs.python.org/2/library/urlparse.html#ur...

Там много чего может встретиться, лучше готовым пользоваться сразу

Действительно, все DNS, как публичные, провайдерские, так и локальные выполняют одну функцию.

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

Рабочие станции, обращаясь к вашему DNS, пытаются разрешить имя для ресурса. Здесь два варианта: либо это ресурс внутри домена и он отвечает клиенту, либо это внешний ресурс и нужно обращаться к вышестоящему серверу (рекурсивным запросом или напрямую).
Вышестоящим сервером могут быть либо настроенные сервера пересылки (обычно DNS провайдера), либо корневые.

Почему имеет смысл настроить DNS провайдера как сервер пересылки? По той же причине: они могут выполнять некоторые дополнительные функции как кэширование, которое сократит время запроса, так и географические привязки (местные узлы CDN крупных сервисов, например).

В общем-то, структура DNS является древовидной и принципы работы сохраняются для более высоких уровней.

if not url.startswith("http:"):
  url = baseUrl + url

Телефония:
В каждом подразделении - отдельные сети для телефонов

10.10.0.0/24
10.11.0.0/24
10.12.0.0/24

На маршрутизаторах подразделений - маршрут из сети телефонии до АТС (через vpn-линк)
На асе - маршруты до сетей телефонии через нужные линки.
Доступ резрешен только между сетями телефонии и АТС + доступ к админке телефонов и АТС откуда нужно
Девайсы:
В каждом подразделении - отдельные сети для девайсов

10.20.0.0/24
10.21.0.0/24
10.22.0.0/24

На маршрутизаторах подразделений - маршрут из сети девайсов до девайс-роутера
На асе - маршруты до сетей девайсов через нужные линки и маршрут до девайс-роутера
На R3 - маршруты до сетей девайсов через асу
Далее - или договариваетесь с девайс-роутером - чтобы пропускал ваши сети - или настраиваете нат для сетей девайсов на R3
Доступ разрешен только между сетями девайсов и девайс-роутером (ну и админка)

По операторам связи врятли вы найдете что-то подобное. Только на таких форумах, как вы указали.
Конечно, про аварию можно сообщить самому оператору связи.

На самом деле вам стоило бы почитать какую-нибудь книжку по электротехнике.

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

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

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

Тут можно посчитать емкостное сопротивление, нужно иметь в виду, что после диодного моста частота переменной составляющей тока будет 100Гц

---

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

@Londoner посмотрите TeamViewer
И еще взгляните на ammyy admin и LiteManager free, может Вам больше понравятся. :)

1) Ваше понимание общей архитектуры - отстой (ознакомьтесь хотя бы с терминами, что бы не писать такие вещи)
2) Ваше понимание об инструментах реализации - отстой (проекты делаются не инструментами, а разработчиками. А разработчики порой знают одни инструменты и совершенно не знакомы с другими. И в то же время остаются гениальными)
3) Ваше понимание управления проектами - отстой (управленческая деятельность вообще показательна в плане того, что без практики от теории толк только отрицательный)
4) Ваше желание распараллелить процесс старо как мир и само по себе не работает (почитайте Мифический человеко-месяц)
5) Ваше желание оставить все в тайне (даже от разработчиков? :) ) - отстой. С ним более-менее успешно справляется разве что майкрософт.
6) Идеи сами по себе - отстой, ничего не стоящие.
7) Ваше желание выучить программирование ради проекта - не работает.

Что делать, если есть непреодолимое желание замутить проект исходя из личной идеи (продиктованной рынком или нет? ... неординарная мысль в наше время, неправда ли?):
1) Заразить своей идеей технически грамотного человека, которому вы сможете доверять процентов, эдак, на 99. И доверить техническу сторону ему.
2) Найти инвестора, который по счастливой случайности не заметит, что вы не знаете, как нужно работать, взять у него денег и нанять менеджера, который знает, что делать и кому сколько платить.

P.S. Разработка ПО - настолько широкая тема, что за более чем 40 лет серьезного коммерческого применения даже самые базовые части процесса не могут быть формализованы и решены универсально.

Нельзя сказать, что нужно делать. Можно сказать, какой путь вероятнее всего будет предпочтительнее в данном конкретном случае (задача + контекст + команда + ресурсы).