Это моя ситуация:
У меня есть сервер Linux / медиацентр с Windows-клиентом.
Моя цель - дистанционное управление ритмбоксом среди прочего.
Я сделал это, используя plink (Windows CliSsh Toy).
Проблема в том, что запуск сеанса ssh, вход в систему и отправка команды, по понятным причинам, очень медленный. Когда у меня был сервер Windows, я использовал инструмент под названием psexec, который был почти мгновенным.
Есть ли способ ускорить этот процесс? Либо как-то отправка команд с запросом на вход, что должно показать некоторое улучшение. Или поддерживая постоянное соединение ssh, которое я могу использовать. (в конце команды введите dcs).
Дополнительная информация:
На моей машине с Windows я использую летучую мышь, например:
plink -ssh -l username -pw pass myipaddress "/home/username/bin/skip"
На моей машине linux файл пропуска bash выглядит примерно так:
//needed to get around a x11 error caused by controlling rhythmbox over ssh<br/>if its an ssh connection <br/> copy the dbusaddress<br/>fi<br/>rhythmbox-client --next //the cli wrapper for rhythmbox
Дальнейшие исследования:
Похоже, единственный способ сохранить соединение ssh открытым / поддерживаемым как сервис. Это кажется выполнимым, поскольку существует потребность в настройке туннелей ssh (для обхода межсетевых экранов). Оттуда мне понадобится способ отправить команды командной строки этому существующему соединению или повторно использовать это соединение.
Другой вариант, конечно, НЕ использовать ssh. Черт, у меня уже есть связь через общие папки с файлами samba, и там нет никаких лагов. Могу поспорить, что мог бы поставить сервисную сторону Linux, которая проверяет наличие измененного файла. Затем есть клиентская сторона ap, которая изменяет указанный файл. Удивительно хакерски, но пока это кажется лучшим вариантом. И под лучшим я имею в виду единственный, который сокращает контрольный лаг. Должен быть лучший способ, чем этот, я не могу быть единственным ботаником, использующим Linux в качестве медиа-центра, которому нужны пульты дистанционного управления. Этот тип перемещает тему из stackoverflow в superuser, но это нормально.