Ну в таких условиях теоретическое решение вижу, хоть оно мне активно не нравится.
Суть - в обычных условиях микротик в качестве шлюза по умолчанию отдаёт адрес роутера. Если он регистрирует падение канала - начинает в качестве шлюза отдавать свой адрес, маршрутизируя в резервного провайдера, а сам постоянно толкается к основному провайдеру. Определив восстановление канала, возвращает всё к обычным настройкам.
Проблема - в оперативной перестройке настроек клиентов. Это в принципе можно решить экстремальным уменьшением времени выделения адреса, заставить клиентов чуть ли не каждые несколько минут обновлять аренду - некрасиво, но в теории работоспособно.
На практике я бы такое делать не стал. Лучше в схему воткнуть второй микротик, гигабитный, и на него перенести маршрутизацию в Инет и резервирование канала. А ВПНы уж пусть остаются на старом.
DHCP сервер только у микротика, все клиенты сети считают шлюзом микротик.
С чего бы? Это у тебя Микротик настроен так, что в качестве шлюза по умолчанию он отдаёт свой адрес. А ведь можно и иначе настроить. И тогда узлы будут получать адреса и прочие настройки от Микротика, а в инет ходить самостоятельно, как нарисовано на второй схеме.
Из текущего местоположения проводим прямую, максимально близко проходящую от точки назначения.
Из точки назначения проводим прямую, максимально близко проходящую к текущему местоположению и пересекающую первую.
В области их пересечения всегда существует быстрый переход с одной прямой на другую за 1 ход.
ЕМНИП алгоритм применим, если координаты различаются больше чем на +/- 3.
Начал читать Троелсена (Язык программирования С#7)
Не путайте справочник и самоучитель. Первое предназначено для профессионалов, причём по большей части - чтобы быстро вспомнить то, что выбросил из головы за ненадобностью и перегруженностью.
А вообще лучше начинать с курсов для начинающих. Типа:
Ну вот теперь сервер гарантированно слушает нужный интерфейс и порт. Пробуй подключаться.
Если подключение не пройдёт - разбирайся, что гадит... но это уже не проблема MySQL... на всякий случай можешь попробовать телнетом стукнуться на 3306 и тупо убедиться, что MySQL реагирует на попытку коннекта.
Согласно руководству сейчас конфиг файл выглядит так
Остановите MySQL-сервер.
Проверьте, что в строке запуска сервера отсутствует опция --skip-networking, при наличии удалите её.
Раскомментируйте параметр port=.
Откорректируйте bind-address= и укажите адрес сетевого интерфейса сервера.
Запустите MySQL-сервер и убедитесь, что netstat показывает, что MySQL слушает порт 3306 на внешнем интерфейсе.
Если после перезапуска не будет изменений - значит, неверно определён используемый конфигурационный файл
Вы как-то не так трактуете термин "производительность". Усложнение схемы, добавление в неё любого объекта или свойства в принципе не способно улучшить производительность.
может ли существовать подобная двойная связь между двумя таблицами
Запросто.
Например... ну, скажем, список интересов пользователя, причём один из интересов является "основным/приоритетным". Связь Пользователь - Интерес является типичной M:N, ибо интерес является мультиатрибутом, и использует связующую таблицу, тогда как связь Пользователь - Приоритетный интерес является связью 1:N, ибо приоритетный интерес является простым атрибутом, и связь оформляется дополнительным полем в таблице пользователей, ссылающимся на таблицу интересов.
Ну или то же на материале фильм-жанр... и т.д., и т.п.
Чередование единичных и нулевых битов в маске? Это называется "разреженная маска".
Было дело - родились на волне перехода к classless networks как предложение. И до сих пор формально допустимы. Даже мелькали, помнится, в драфтах стандартов - но до финальной версии не дожили. Реально - сейчас не поддерживаются практически нигде и ничем. Попытка использования приводит к сообщению об ошибке.
Из очень старого помню, что поддерживались в Novell Netware, до версии 3.12 точно, но только на сервере, клиенты уже плевались.
Не вижу проблемы. Система позволяет генерировать неограниченное количество файлов, для которых достоверно известно дешифрованное содержимое, что позволяет провести атаку почти любого типа. Другой вопрос, сколько это потребует времени и вычислительных ресурсов.
Суть - в обычных условиях микротик в качестве шлюза по умолчанию отдаёт адрес роутера. Если он регистрирует падение канала - начинает в качестве шлюза отдавать свой адрес, маршрутизируя в резервного провайдера, а сам постоянно толкается к основному провайдеру. Определив восстановление канала, возвращает всё к обычным настройкам.
Проблема - в оперативной перестройке настроек клиентов. Это в принципе можно решить экстремальным уменьшением времени выделения адреса, заставить клиентов чуть ли не каждые несколько минут обновлять аренду - некрасиво, но в теории работоспособно.
На практике я бы такое делать не стал. Лучше в схему воткнуть второй микротик, гигабитный, и на него перенести маршрутизацию в Инет и резервирование канала. А ВПНы уж пусть остаются на старом.