Windows Подключение в режиме удаленного доступа.

[Andi]

Андрей, ну а как с моим письмом? Жду ответ.

Я еще раз переслал тебе ответ, а это часть возможно будет интересна всем.

КСЛ динамически строит таблицы маршрутизации и сам знает как переслать сообщение адресату.
Структура в драйвере (ComCLB.Str), с точки зрения маршрутизации, фактически нужна только для того чтобы осуществить локальную маршрутизацию, т.е. направить пакет с сообщениями тому слоту ММИ в диспетчерской, в который включен КСЛ+, а дальше маршрутизирует КСЛ. Именно по этому в центральной диспетчерской (ЦД) в ComCLB.Str в качестве связи можно указать УМ, с которым КСЛ в ЦД не имеет прямой IP связи. Сообщения из ЦД КСЛ посылает в локальную диспетчерскую (ЛД), а уже КСЛ в ЛД пересылает сообщение в УМ, к которому подключено оборудование. Не знаю поддерживает ли КОРК динамическую маршрутизацию, в данном случае это и не нужно, но в КОРК есть ошибка - он не отвечает на сообщения посланные с другого УМ, т.е. если сообщение пришло не из УМ0, то КОРК не отвечает на него. Соответственно MScan не видит КОРК и не возможно из ЦД увидеть состояние лифтов через КОРК.

 

[Andi]

Почему бы не снабдить ПО неким промежуточным сервером, удаленное подключение к которому проходило бы по более безопасному и удобному порту, нежели 135, и который в свою очередь уже локально коннектился бы к драйверу? То есть дать возможность использовать две реализации: как COM-объект и как обычный клиент-сервер.

Все упирается в соотношение затрат и эффекта, как у нас (разработкичков), так и у эксплуатирующих организаций.
Как я уже писал, наличие КСЛ+, позволяет безопасно подключаться по открытым сетям, а в закрытых сетях и с 135 портом поблем быть не должно.

 

[revit]

Соответственно MScan не видит КОРК и не возможно из ЦД увидеть состояние лифтов через КОРК.

Андрей возвращаюсь к теме удаленного подключения.
В моем случае полноценно подключиться к центральному компу не получается?
1. 135 порт на файерволе закрыт.
2. Через КСЛ не видятся лифты с КОРКами
Можно ли как-то исправить ошибку КОРКов программно не трогая сами КОРКи? Ведь информация все-таки проходит с этих лифтов на удаленный комп с УМ0 (центрального). Хаотически и долго, но все же появляются квадраты. Может как-то их перенаправлять?

 

[Andi]

Можно ли как-то исправить ошибку КОРКов программно не трогая сами КОРКи? Ведь информация все-таки проходит с этих лифтов на удаленный комп с УМ0 (центрального). Хаотически и долго, но все же появляются квадраты. Может как-то их перенаправлять?

Информация от лифтовых блоков, поключенных через КОРК, на удаленный компьютер поступает если вдруг произойдет рестарт КЛШ, их обслуживающого. В случае рестарта, КЛШ теряет адрес своего администратора (в данном случае 0:8) и рассылает информацию о своем состоянии и состоянии ЛБ широковещательно. Широковещательные сообщения доходят до компьютера в удаленном узле. При изменении состояния лифтового блока КЛШ оповещеет об этом администратора (0:8), а уже драйвер ComCLB пересылает эти сообщения на компьютер в удаленном узле, где они опять же отображаются. Только непосредственные запросы от компютрера в удаленном узле не доходят до ЛБ, расположенных за КОРК.
КОРКИ сейчас не рекомендованы к применению, соответсвенно делать что-то для перенапраления адресных сообщений от удаленных узлов к ЛД за КОРКами нет смысла, а для реализации этого перенаправления пришлось бы изменять протокол взаимодействия устройств в сети "Обь", что очень дорого. Скорее можно попросить производителей КОРКов исправить микропрограммы.

 

[revit]

Скорее можно попросить производителей КОРКов исправить микропрограммы.

Вот это по моему самый сложный путь. Снять 25 КОРКов с объектов и отправить их производителю?
А закачку микропрограмм они наверняка не поддерживают.
Остается 135 порт?

 

[Andi]

Остается 135 порт?

Можно сделать в УМ0 терминальный сервер на основе W2000 или W2003, на котором будет работать драйвер, и удаленно подключаться к терминальному серверу (удаленному рабочему столу) с любой точки и запускать там (в терминальной сессии) MPult и др.

 

[revit]

Да, вот пробуем терминал через встроенную функцию мессенджера в ХР. А без него не знаешь как подключиться в терминале XP?

 

[Andi]

Да, вот пробуем терминал через встроенную функцию мессенджера в ХР. А без него не знаешь как подключиться в терминале XP?

Терминальный режим поддерживается серверами W2000 и W2003, его нужно просто там установить. Терминальный сервер может работать в двух режимах - режиме администрирования и в режиме приложений. В режиме администрирования возможно только два внешних подключения, но зато нет лицензионных ограничений, что, в общем то, может и хватить.
На удаленной клиентской машине XP подключение производится с помощью "Подключения к удаленному рабочему столу"

 

[revit]

Терминальный режим поддерживается серверами W2000 и W2003, его нужно просто там установить. Терминальный сервер может работать в двух режимах - режиме администрирования и в режиме приложений. В режиме администрирования возможно только два внешних подключения, но зато нет лицензионных ограничений, что, в общем то, может и хватить.
На удаленной клиентской машине XP подключение производится с помощью "Подключения к удаленному рабочему столу"

Так это и у XP Pro есть, котрый в ЦД стоит.

 

[Andi]

Так это и у XP Pro есть, котрый в ЦД стоит.

К рабочему столу XP действительно можно подключаться удаленно, но только одному пользователю в одно время и когда нет консольного пользователя (не зарегистрирован).

 

[revit]

К рабочему столу XP действительно можно подключаться удаленно, но только одному пользователю в одно время и когда нет консольного пользователя (не зарегистрирован).

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

 

[Andi]

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

Если нужно не просто подглядывать за работой оператора, а самому полноценно работать, то без терминального сервера (соответсвенно сервреров 2000 или 2003) не обойтись.

 

[revit]

Если нужно не просто подглядывать за работой оператора, а самому полноценно работать, ...

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

 

[vlasoff]

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

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

 

[revit]

Да и купить его для диспетчерского компа (сервер2003) -дороговато, тем более что уже XP стоит лицензионная.

 

[revit]

Поставили пробный сервак на 2003, через него удаленным терминалом подключаюсь к диспетчерскому драйверу порта. Очень удобно при запуске и наладке удаленного УМ с КСЛ-Е. Также для контроля запускаю на нем Мпульт, но вот проблема -когда МПульт запущен под одним удаленным пользователем, второй не может его запустить. Я так понимаю программа однопользовательская? Можно это как-то поправить?

 

[Andi]

...но вот проблема -когда МПульт запущен под одним удаленным пользователем, второй не может его запустить. Я так понимаю программа однопользовательская? Можно это как-то поправить?

Вообще MPult есть специальная защита от загрузки второго экземпляра программы. Она работает, если попытаться загрузить MPult второй раз в одной клиентской сессии. Если попытаться загрузить Mpult в одной сессии (т.е. одним удаленным пользователем), то быдет выдано сообщение "Программа уже загружена и не может быть загружена повторно". В разных клиентских сессиях (т.е. разными удаленными пользователями) можно загружать по одному экземпляру MPult на сессию, правда если загружать MPult из одной папки, то при загрузке MPult вторым пользователем появится сообщение "Невозможно открыть файл журнала, возможно от поврежден. Удалите или переименуйте Prot.Log, если он существут", после чего MPult прекращает работу. Происходит это из-за того , что файл журнала Port.Log монопольно захватывается первым экземпляром MPult, а второй экземпляр уже не может использовать Prot.Log.
Для запуска второго экземпляра MPult нужно скопировать папку MPult внутри папки LKDS в другую папку, например, в папку MPult_1 (для следующего MPult_2 и т.д.). И загружать MPul.Exe вторым пользователем уже из папки MPult_1. Нужно только еще изменить настройки второй установки MPult - использовать другие папки для очистки журнала и экспорта CSV файла, изменить идентификатор (номер) диспетчерской в параметрах пульта. Это нужно что бы не путались экспортируемые файлы от разных установок MPult.

 

[revit]

Понятно. Спасибо Андрей за разъяснения.

 

[revit]

Опять непонятки с удаленным подключением. На серваке драйвер и мпульт удаленно подключаются только от имени диспетчера, под которым ставился дистрибутив, хотя при установке я ставил "для всех" и был другой пользователь-администратор, в настройках безопасности драйвера также стоит "всё для всех". Почему так?

 

[Andi]

На серваке драйвер и мпульт удаленно подключаются только от имени диспетчера, под которым ставился дистрибутив

Что бы уточнить терминологию - под удаленным подключением в драйверу ComCLB понимается подключение программы (MPult, например) к ComCLB, который (ComCLB) запущен на другом компьютере. При подобном подключении, если в сети нет контроллера домена, нужно на компьютере, где будет работать ComCLB, завести того же пользователя (с тем же паролем), что и пользователь, под которым запускается MPult.