Так оно так и будет работать :) МФУ получает адрес от центрального dhcp, который выдает адреса из пула, который соответствует адресному пространству релея. центральный dhcp сервер прописывает мфу в днс в центральной локации. при первом обращении к мфу по имени в филиале днс на микротике, не найдя такой записи, посылает запрос на днс центральной локации и отдает его клиенту, при этом кэшируя. далее все определяется временем кэширования. В dhcp также можно играть с временем аренды. При установке времени аренды ~1 сутки кратковременные пропадания vpn не критичны. для длительных пропаданий - локальный сервер dhcp с задержкой отдачи, чтобы в APIPA клиентов не искать, если к ним доступ потребуется.
другой вариант - полноценные dhcp и dns серверы в филиале с отдачей зоны на уровень центральной локации.
а что со старым дросселем? вещь типа стального шара - ни разу не видел сгоревшего, только физически разбитый(ферритовое кольцо). дроссель, как и конденсатор, проще взять с разбора. например из старого компьютерного блока питания. смотреть по сечению провода.
задача простая:
первый ввод информации (n) - целое число, определяющее количество последующих вводов информации (строки), содержащих данные для поиска.
последний ввод (n+1) -строка, информация для поиска в данных для поиска.
общее количество вводов - n+2
Выборка по текущей дате и количеству повторений равному больше 0 или специаальному значению. Далее для выборки апдейтом уменьшаем количество повторений на 1 и меняем дату на следующую. Для специального значения повторений (бесконечное количество. Значение например =-1) просто меняем дату на дату следующего вызова.
armodim, многоядерность там на уровне rphost. Один rphost - одно ядро. Ядро лучше повысокочастотнее. Т.е. для 1с лучше меньше ядер, но с большей частотой. Для СУБД может оказаться наоборот.
5В/20ом=250мА. Дальше справочник и любой транзистор с током коллектора не меньше. Не забыть обмотку реле зашунтировать диодом. Схем подключения реле - тысячи их...
У Вас не проигрыватель, у Вас надстройка над проигрывателем Windows Media Player. Если сможете реализовать (а это возможно, хотя требует времени) необходимый Вам функционал данного проигрывателя, то сможете решить задачу в том виде, как Вы ее сформулировали. Реализацию проигрывателя можно посмотреть например здесь.
Таки да. Причем State , Activity и Sequence - это уровень проектирования алгоритмов в том самом UML (хотя может использоваться и для процессов). Ниже - только диаграмма классов. Но как было справедливо замечено выше Vito Omberto, руками рисовать ее большого смысла не имеет, т.к. на живой системе очень быстро теряет актуальность. Использовал только на стадии обсуждения идеи реализации или для реверса чужого кода.
Т.е. понимание, какие объекты и каким образом взаимодействую важнее знания о том, как именно это реализовано в коде.
Винапи не набор заклинаний, а низкоуровневые функции. Ничего экстраординарного они не делают. Для передачи Inproc-Outproc необходимо иметь возможность организовать между ними ресурс совместного доступа, с которым могут работать оба процесса. В Вашем случае выбор ограничен методами объекта WindowsMediaPlayer и способами, которыми он позволяет взаимодействовать. Т.е. можно создать для взаимодействия со стороны Vb например Named shared memory, но будет ли с этим работать WindowsMediaPlayer - не знаю. И в принципе - это тоже самое, что было предложено: воспроизведение файла через выгрузку на диск.
Поэтому в Вашем случае проще и разумнее всего либо реализовать проигрывание через выгруженный файл, либо отказаться от использования компоненты WindowsMediaPlayer и проигрывать файл своими силами (вот в этом случае API) Вам поможет.
Пы.Сы. Можете попробовать проигрывать через PlaySound. Оно умеет с ресурсами.
Зря Вы так про проектирование. Только разрисовывать нужно не взаимоотношение классов, а взаимоотношения процессов, которые автоматизируются, и объектов, которые участвуют в этих процессах. Тогда будет понимание, что и как должен делать тот или иной модуль системы.
По факту для меня полезными оказались Use case, Activity, Sequence и State диаграммы. Сами процессы (как верхний уровень) на мой вкус удобнее разрисовывать в нотации IDEF. Но любая разработка начинается таки с бумажки и карандаша: формулируются требования к системе и декларируются базовые принципы. Программа (ее прототип) -суть есть отражение автоматизируемых процессов , объективно существующих, на код. Любая реализация процесс в коде является частным случаем.
По поводу остального - полностью согласен.
Для ТТЛ было эмпирическое правило 10/n кОм, где n - количество ног к одному резистору подтяжки. За больше 10 ног на резистор пороли, т.к. начинают вылезать наводки. Мощность вероятно выбрана отфонарно, с минимальным размером установочного элемента, но не смд - это надо смотреть, что в набор проектировщики положили.
YMakeev,
Неа... По условию задачи нужно изменить точку доставки маркера авторизации не меняя привязку к учётной записи. Ситуация с токенами следующая
1. Генерируем сертификат;
2. Привязываем его на учётную запись на овермного серверах, которые не в домене (т.е. вручную);
3. Сохраняем сертификат на токен;
4. Выдаём специалисту для использования;
5. Специалист уходит вместе с токеном;
6. Упс...Отзыв сертификата! (Плюс надо ещё иметь уверенность, что все серверы лист отзыва прочитали);
7. Новый специалист - goto п.1
другой вариант - полноценные dhcp и dns серверы в филиале с отдачей зоны на уровень центральной локации.