Алексей Тутубалин, конечно нет. у каждого из них только по одному оптическому порту. DMC-F20SC-BXD от DMC-F20SC-BXU отличаются только частотами, на которых идёт приём и передача: в одном из них используется свет с длиной волны 1310 нм для передачи и 1550 нм для приёма, в другом же - наоборот. таким образом это парные устройства.
если хочется обязательно воткнуть все три "ресивера" в один "трансмиттер", то в его роли должен выступать, например, сетевой коммутатор с нужным количеством свободных оптических портов.
lilikon, всякое может быть, небольшие провайдеры "местного разлива", возможно, пойдут на встречу в этом вопросе. вообще же ухудшение предоставляемого качества или объёма (как в вашем случае) услуг провайдером - с их стороны не самый верный поступок.
Donald_Duck, зайти в оснастку служб (services.msc) в папке администрирования, зайти в службу сфинкса и посмотреть, от какого пользователя запускается служба во вкладке "вход в систему". если там указано "с системной учётной записью" - это пользователь "СИСТЕМА".
права на папку - в свойствах папки во вкладке "безопасность".
Илья Прибиль, для того чтобы запрос от B мог дойти до E при указанных данных (а именно - наличие маршрутизатора 1 между ними), должен соблюдаться ряд условий: B и E должны иметь IP-адреса из разных подсетей; B и E должны иметь маршруты в эти подсети, для которых маршрутизатором назначен маршрутизатор 1; маршрутизатор 1 должен быть настроен для работы с пакетами из подсетей, в которых находятся B и E.
если предположить, что эти условия выполняются, тогда:
- B формирует пакет для E:
-- проверяется IP-адрес назначения (IP-адрес E) на предмет того, находится ли он в той же подсети, что и IP-адрес источника (IP-адрес B) - не находится.
-- проверяется, есть ли в B маршрут до подсети, в которой находится IP-адрес назначения - есть, с маршрутизатором 1.
-- выясняется MAC-адрес маршрутизатора 1:
--- проверяется наличие в ARP-таблице узла B записи с MAC-адресом маршрутизатора 1 - допустим, его нет.
--- тогда рассылается широковещательный ARP-запрос MAC-адреса узла, у которого IP-адрес маршрутизатора 1, а именно формируется пакет с MAC-адресом источника (MAC-адрес B), MAC-адресом назначения (поскольку MAC-адрес ещё неизвестен - используется широковещательный MAC-адрес FFFF-FFFF-FFFF) и содержимым в виде ARP-запроса "какой MAC-адрес у узла с IP-адресом маршрутизатора 1?":
---- пакет с ARP-запросом уходит с B и попадает в свитч 6. если в MAC-таблице свитча 6 ещё нет записи о том, на каком порту висит хост с MAC-адресом узла B, то эта запись теперь появляется. свитч 6 рассылает этот пакет дальше по всем портам, кроме исходного, потому что этот пакет широковещательный.
---- пакет попадает на все напрямую связанные со свитчом 6 устройства (хаб 5, A, C). компы его отбрасывают, потому что их IP-адрес не соответствует искомому IP-адресу в ARP-запросе из пакета, хаб рассылает на все порты, потому что таким вот он дурачком уродился.
---- пакет попадает на комп I, где отбрасывается по той же причине, что и пунктом выше, и на свитч 2. если в MAC-таблице свитча 2 ещё нет записи о том, на каком порту висит хост с MAC-адресом узла B, то эта запись теперь появляется. свитч 6 рассылает этот пакет дальше по всем портам, кроме исходного, потому что этот пакет широковещательный.
---- ... таким образом пакет доберётся до маршрутизатора 1. этот маршрутизатор отвечает на пакет ARP-ответным пакетом с MAC-адресом источника (MAC-адрес маршрутизатора 1), MAC-адресом назначения (MAC-адрес источника из пакета с ARP-запросом), в котором говориться, что "у узла с тем IP-адресом, который вас интересует, MAC-адрес маршрутизатора 1".
---- пакет возвращается обратно на B через хабы (они рассылают пакет на все порты, в том числе и компам, которые их отбрасывают, потому что MAC-адрес назначения - не их адрес) и коммутаторы (в них уже имеется MAC-запись, в которой для MAC-адреса назначения был назначен соответствующий порт, когда через них проходил пакет с ARP-запросом, поэтому пакет с ARP-ответом они будут направлять именно в тот порт, из которого приходил ARP-запрос).
--- B получает ARP-ответ, из которого узнаёт MAC-адрес маршрутизатора 1.
-- в пакет, который всё ещё формируется узлом B для узла E, вставляется MAC-адрес источника (MAC-адрес B), MAC-адрес назначения (MAC-адрес маршрутизатора 1), IP-адрес источника (IP-адрес B), IP-адрес назначения (IP-адрес E), пакет отправляется.
- ... пакет проходит через коммутаторы и хабы тем же образом, что и предыдущий. записи с MAC-адресом назначения в MAC-таблицах коммутаторов уже имеются (появились, когда проходил ARP-ответ), так что коммутаторы отправляют пакеты на порт, в которых этот адрес фигурирует; хабы как всегда шлют пакет всем, но всем всё-равно. пакет приходит на маршрутизатор 1.
- маршрутизатор 1 берёт из пакета IP-адреса источника и назначения и смотрит, есть ли у него в таблице маршрутизации правило, в соответствии с которым ему следует переслать этот пакет. по условиям задачи мы решили, что такое правило есть.
- маршрутизатор 1 меняет в пакете от B к E MAC-адрес источника на свой MAC-адрес.
- маршрутизатор 1 меняет в пакете MAC-адрес назначения на MAC-адрес E:
-- проверяется наличие в ARP-таблице маршрутизатора 1 записи с MAC-адресом узла E - допустим, её нет:
--- ... происходит то же самое, что и было в подобной ситуации при отправке пакета с узла B: формируется широковещательный ARP-запрос, на этот раз во вторую подсеть, ну и так далее...
- ... пакет отправляется через коммутаторы и хабы второй подсети (по факту - через коммутатор 3, он там один) на узел E.
прошла половина милисекунды. хотя, если на каком-то из хабов возникла коллизия, то не факт.
Дима Долготер, всё зависит от датчика. я не могу знать, каким образом опрашивается ваш датчик, но если вы кинете сюда его модель - кто-нибудь, я думаю, посмотрит, как это делается в его случае. даже непонятно, это просто термопара без обвязки или что-то с контроллером и каким-либо стандартным интерфейсом а-ля USB.
Александр, да, не подумал. при самоподписанных публичный ключ должен быть заслан на сервер телеграма отдельной командой. я для этого в своё время пользовался этой инструкцией, там есть секция про отправку ключа через curl.
АртемЪ, ну по дефолту они и пробрасываются, если приложение запускается как RemoteApp. ничего и настраивать не надо как правило. уж не скажу, как было в 2008, но с 2012 R2 это работает именно так по дефолту - у пользователя внутри приложения, запущенного через RemoteApp сетевые диски клиентской машины рядом с серверными томами.
