[Serializable]
abstract class Response
{
protected Response(string hostName)
{
_HostName = hostName;
}
public abstract void Perform(IResponseContext context);
string _HostName;
public string HostName
{
get{ return _HostName; }
}
}
interface IResponseContext
{
void ScreenshotRecieved(Image screenshot, string hostName);
}
interface ICommandContext
{
Image TakeScreenshot();
bool TerminateProcess(int id);
bool TerminateProcess(string name);
string HostName { get; }
}
[Serializable]
abstract class Command
{
public abstract Response DoCommand(ICommandContext context);
}
class TakeScreenshotCommand : Command
{
public override Response DoCommand(ICommandContext context)
{
Image image = context.TakeScreenshot();
ScreenshotResponse retval = new ScreenshotResponse(context.HostName, image);
return retval;
}
}
class ScreenshotResponse : Response
{
public ScreenshotResponse(string hostname, Image screenshot)
: base(hostname)
{
_Screenshot = screenshot;
}
Image _Screenshot;
public override void Perform(IResponseContext context)
{
context.ScreenshotRecieved(_Screenshot, HostName);
}
}
Как лучше реализовать проект подобный программе RAdmin?
На мне висит много проектов...:( и никто помочь даже не пытается...
Сейчас пока не требуется код с вашей стороны, требуются советы как лучше и как логически реализовать.
Итак... Представили предпода:) ему необходимо следить за плохими студентами:) надо написать сетевого админа... Все это дело пишем на VisualBasic .Net 2008.
На компе предпода отображается список компов... Он выбирает комп и может как минимум увидеть список процессов, убить процесс, вывести сообщение, просмотреть что видно на мониторе студента, перезагруз. комп, выключить...
Теперь о логической работе? Как сделать это? Как посоветуете?
На компьютере студентов располагаем свою службу Windows, которая будет принимать команды? Только вот я вообще еще со службами не умею работать... Или как то иначе?
На компе предпода. Какой интерфейс лучше сделать? MDI окно с вложенными дочерними для каждого компа студента, т.е у MDI будет список всех компьютеров, там выбираем комп и появляется дочернее окно с PictureBox для просмотра его экрана и кнопок для комманд... Или без mdi но с TABCONTROL? Или еще как? Как лучше?
А как сделать лучше обмен между сервером и клиентом? Создать отдельную dll с классом типа:
private class Trans
public command as string
public list (of object)
End Trans
и сериализировать его для передачи комманд или как то иначе? Как?
Предложения есть? Как можно подробнее излагайте свои мысли.
Пишу в раздел Microsoft .Net framework, а не в "студентам" поскольку писать буду на VB.NET.
И после того, как вы выскажите мнения попытаемся использовать уже код на этом языке программирования...
Спасибо всем за внимание:)
Сейчас пока не требуется код с вашей стороны, требуются советы как лучше и как логически реализовать.
Итак... Представили предпода:) ему необходимо следить за плохими студентами:) надо написать сетевого админа... Все это дело пишем на VisualBasic .Net 2008.
На компе предпода отображается список компов... Он выбирает комп и может как минимум увидеть список процессов, убить процесс, вывести сообщение, просмотреть что видно на мониторе студента, перезагруз. комп, выключить...
Теперь о логической работе? Как сделать это? Как посоветуете?
На компьютере студентов располагаем свою службу Windows, которая будет принимать команды? Только вот я вообще еще со службами не умею работать... Или как то иначе?
На компе предпода. Какой интерфейс лучше сделать? MDI окно с вложенными дочерними для каждого компа студента, т.е у MDI будет список всех компьютеров, там выбираем комп и появляется дочернее окно с PictureBox для просмотра его экрана и кнопок для комманд... Или без mdi но с TABCONTROL? Или еще как? Как лучше?
А как сделать лучше обмен между сервером и клиентом? Создать отдельную dll с классом типа:
private class Trans
public command as string
public list (of object)
End Trans
и сериализировать его для передачи комманд или как то иначе? Как?
Предложения есть? Как можно подробнее излагайте свои мысли.
Пишу в раздел Microsoft .Net framework, а не в "студентам" поскольку писать буду на VB.NET.
И после того, как вы выскажите мнения попытаемся использовать уже код на этом языке программирования...
Спасибо всем за внимание:)
у вас ничего не выйдет. точка.
почему? потому что вы начали сразу думать о деталях реализации, когда еще нету ИДЕИ. вы изучили рынок? изучили имеющиеся продукты? выяснили, что вас в них не устраивает и какие плюсы можно взять от них? нет? тогда с вами не о чем говорить :(
почему? потому что вы начали сразу думать о деталях реализации, когда еще нету ИДЕИ. вы изучили рынок? изучили имеющиеся продукты? выяснили, что вас в них не устраивает и какие плюсы можно взять от них? нет? тогда с вами не о чем говорить :(
Цитата: squirL
у вас ничего не выйдет. точка.
почему? потому что вы начали сразу думать о деталях реализации, когда еще нету ИДЕИ. вы изучили рынок? изучили имеющиеся продукты? выяснили, что вас в них не устраивает и какие плюсы можно взять от них? нет? тогда с вами не о чем говорить :(
почему? потому что вы начали сразу думать о деталях реализации, когда еще нету ИДЕИ. вы изучили рынок? изучили имеющиеся продукты? выяснили, что вас в них не устраивает и какие плюсы можно взять от них? нет? тогда с вами не о чем говорить :(
Ну.... знаете..... Ваш подход верен.... Но я не буду выпускать продукт на массовый рынок. Это колледжовская работа..... тут сильно парится не нужно.... Ну а если говорить о твоем подходе....
Ну вот я работал с Radmin (Remote Administrator версии 2.2 и 3.2)....
Ну понравилось мне в принципе все..... Кроме слова Shareware))
Ну помоему при передаче файлов нельзя докачивать после обрыва(это в версии 2.2, в 3.2 незнаю....)
В общем равняться хочу на него...
но там интерфейс Viewer'a странен.... Для каждой операии открывается отдельное окно.... Реализовать не очень легко будет....
P.S. Еще мысли?)))
Принципиально организовать взаимодействие с удаленной машиной можно посредством .NET Remoting-а и сериализации объектов (на целевую машину нужно свой сервис ставить). Хотя конечно, еще остается WMI для управления (но это отдельная история).
Признаться, я не представляю как можно (быстро!) получать изображение с дисплея(ев) целевой машины. Функционал периодических снимков экрана - это достаточно просто, а вот получение функционала mstsc или radmin требует глубокого изучения графической системы виндов.
Признаться, я не представляю как можно (быстро!) получать изображение с дисплея(ев) целевой машины. Функционал периодических снимков экрана - это достаточно просто, а вот получение функционала mstsc или radmin требует глубокого изучения графической системы виндов.
это платформозависимо и требует монструозного .NET фреймворка.
автор - возьмите бесплатный vnc server & viewer (гугл покажет где) и изучите - что и куда. там открытые исходники. просто разберитесь
автор - возьмите бесплатный vnc server & viewer (гугл покажет где) и изучите - что и куда. там открытые исходники. просто разберитесь
Цитата: squirL
это платформозависимо и требует монструозного .NET фреймворка.
Смотря для чего ;) По мне так лучше сто мегабайтов уже гарантированно отлаженного кода, чем в очередной раз прикручивать какуюнить фиговину типа XML парсера, HTML-шаблонизатора или всяко-разного сериализатора.
Цитата: squirL
автор - возьмите бесплатный vnc server & viewer (гугл покажет где) и изучите - что и куда. там открытые исходники. просто разберитесь
У него задача - изобрести велосипед. На .NET-е. Хотя я бы тоже посмотрел в те исходники.
ну так кто мешает изучить исходники и сделать свой велосипед? реализовать RFB на .NET? передрав все что нужно с VNC и переписав это на .NET
За мой совет, конечно, подобает самозабаниться, но автору проще будет так или иначе приобрести Radmin - если я правильно понял, что автору надо решить задачу управления удалёнными компами, а не задачу написания программы, которая позволяет это делать. В таком случае дешевле и проще разобраться с VNC|Radmin|WMI, чем городить непонятно что или переписывать сишный код на дотнете. Тем более, что переписывать на дотнете задача тоже не самая тривиальная.
Цитата: Sanila_san
За мой совет, конечно, подобает самозабаниться, но автору проще будет так или иначе приобрести Radmin - если я правильно понял, что автору надо решить задачу управления удалёнными компами, а не задачу написания программы, которая позволяет это делать. В таком случае дешевле и проще разобраться с VNC|Radmin|WMI, чем городить непонятно что или переписывать сишный код на дотнете. Тем более, что переписывать на дотнете задача тоже не самая тривиальная.
как раз обратное, мне нужно написать программу, а управлять то я и через радмин легко))
Цитата:
ну так кто мешает изучить исходники и сделать свой велосипед? реализовать RFB на .NET? передрав все что нужно с VNC и переписав это на .NET
На каком языке исходники...(потом посмотрю может быть)? смогу ли я? Я кроме VB.Net ни одного языка в принципе незнаю...
Цитата:
Признаться, я не представляю как можно (быстро!) получать изображение с дисплея(ев) целевой машины.
Ну если даже вы не знаете... Может мне забить?:D шучу))
В радмине передается не дисплей целиком, а его изменения. Делается это через миррор-драйвер собственного написания. Тема для вас, судя по всему, неподъемная. Хотя я делал и тупую непрерывную передачу скриншотов целиком с возможностью захвата управления (передача клавиатуры и мыши в обратном направлении). Сильно грузит проц на клиенте.
Цитата: Phodopus
В радмине передается не дисплей целиком, а его изменения. Делается это через миррор-драйвер собственного написания. Тема для вас, судя по всему, неподъемная. Хотя я делал и тупую непрерывную передачу скриншотов целиком с возможностью захвата управления (передача клавиатуры и мыши в обратном направлении). Сильно грузит проц на клиенте.
Ну можно тоже че то типа миррор устроить.... сравнивать по-пиксельно.... и отдавать тока изменившиеся..... долго сравнивать правдо...
А полностью передавать легко.... захватил, серилизовал, отправил, десерилизовал, показал, правдо вот захват управления.... это жесть))
Цитата: NextTime
Ну можно тоже че то типа миррор устроить.... сравнивать по-пиксельно.... и отдавать тока изменившиеся..... долго сравнивать правдо...
А полностью передавать легко.... захватил, серилизовал, отправил, десерилизовал, показал, правдо вот захват управления.... это жесть))
А полностью передавать легко.... захватил, серилизовал, отправил, десерилизовал, показал, правдо вот захват управления.... это жесть))
Оно вам надо? Вроде как, в начале топика вы говорили о статичной картинке и простом наблюдении + завершении процессов и сеансов... Может, этим и стоит ограничиться? Тогда вполне реально.
В принципе можно картинку отправлять наблюдателю каждые 10 секунд, например, это не сильно ресурсоёмко, но картинка уже как бы не статическая.
Цитата: Sanila_san
В принципе можно картинку отправлять наблюдателю каждые 10 секунд, например, это не сильно ресурсоёмко, но картинка уже как бы не статическая.
Ну в этой схеме как бы наоборот надо: именно наблюдатель должен запрашивать картинку. А уж с какой скоростью он будет это делать - его заботы (точнее, надо сделать так, чтобы наблюдатель не мог выполнить новый запрос прежде, чем дождётся результатов предыдущего, и в частности результатов отмены, например).
Цитата: Der Meister
Оно вам надо? Вроде как, в начале топика вы говорили о завершении процессов и сеансов... Тогда вполне реально.
Про эту часть шел разговор....
а про
Цитата: Der Meister
Вроде как, в начале топика вы говорили о статичной картинке и простом наблюдении
несовсем.
Это конечно такой Addition, но все равно хотелось бы уметь такое деать, интересно ведь очень!!!
Пока ограничемся завершением процессов и сеансов конечно, ну выдачей сообщения...
Но тем не менее, мне бы хотелось обсудить передачу изображений, поскльку именно это самое сложное, а не закрытие процессов и выключение компа
Цитата: NextTime
Но тем не менее, мне бы хотелось обсудить передачу изображений, поскльку именно это самое сложное, а не закрытие процессов и выключение компа
Один из вариантов: кодируем изображение в 8-разрядный PNG и пишем в сеть.
Цитата: hardcase
Один из вариантов: кодируем изображение в 8-разрядный PNG и пишем в сеть.
Я тогда в jpg кодировал. Но png несомненно будет лучшим вариантом если передаваться будет не только десктоп с бекграундом-фотографией :). Хотя сеть все-равно грузилась мало. Основная потеря времени состояла как-раз в процессе получения изображения экрана. Даже временем кодирования в jpg при подсчетах пренебрегал, если не путаю.
Цитата: hardcase
Один из вариантов: кодируем изображение в 8-разрядный PNG и пишем в сеть.
Кратко при кратко, скажи как.... Какой класс, процедура?
Цитата: NextTime
Кратко при кратко, скажи как.... Какой класс, процедура?
Bitmap и NetworkStream. Bitmap умеет в заданном формате сохраняться в поток (метод Save). На другом конце можно будет прочитать.
Как думаете, как лучше посторить обмен коммандами и данными?
Вариант:
Открываем 2 порта на сервере и на клиенте. Создаем класс со строковой переменной и массивом объектов на обоих сторонах. В строк. переменную ложим комманду, в массив параметры комманды и отправляем по порту комманд. На сервере(жертве, которую поймали) ловим команду и параметры, десериализируем, и по порту данных отправляем кадры либо активные процессы по тому же принципу: В строковую переменную ложим комманду(напр, "ISendActiveProccessesToYou"), а в массиве шлем названия процессов.
Если нужно посылать кадры(Скриншоты), то в строковую переменную ложим, допустим, "ISendScreens" и переодически посылаем друг за другом такие сереализированные классы по порту данных, не дожидаясь следующего запроса кадра. Если я хочу остановить посылку скринов, то, допустим, шлю комманду "StopScreens" по порту комманд и жертва перестает слать....
Не красивый метод, не спорю, но зато не тратится время на запрос нового кадра(скрина)
Или все таки методом "запрос-Ответ"? Есть идеи по-лучше моих ламерских?))
Вариант:
Открываем 2 порта на сервере и на клиенте. Создаем класс со строковой переменной и массивом объектов на обоих сторонах. В строк. переменную ложим комманду, в массив параметры комманды и отправляем по порту комманд. На сервере(жертве, которую поймали) ловим команду и параметры, десериализируем, и по порту данных отправляем кадры либо активные процессы по тому же принципу: В строковую переменную ложим комманду(напр, "ISendActiveProccessesToYou"), а в массиве шлем названия процессов.
Если нужно посылать кадры(Скриншоты), то в строковую переменную ложим, допустим, "ISendScreens" и переодически посылаем друг за другом такие сереализированные классы по порту данных, не дожидаясь следующего запроса кадра. Если я хочу остановить посылку скринов, то, допустим, шлю комманду "StopScreens" по порту комманд и жертва перестает слать....
Не красивый метод, не спорю, но зато не тратится время на запрос нового кадра(скрина)
Или все таки методом "запрос-Ответ"? Есть идеи по-лучше моих ламерских?))
Цитата: NextTime
Как думаете, как лучше посторить обмен коммандами и данными?
Есть идеи по-лучше моих ламерских?))
Есть идеи по-лучше моих ламерских?))
Создаем дерево классов с абстрактным корнем Command. У него также должен быть какойнибудь абстрактный метод вроде DoCommand() (какие параметры у него будут, поймешь при реализации, сейчас трудно сказать). Все наследники должны быть сериализуемыми. Отправка команды - это ее сериализация в сетевой поток. Получение - это чтение и десериализация из потока. Полученный System.Object приводится к Command и у него вызвается метод DoCommand().
Цитата: hardcase
Создаем дерево классов с абстрактным корнем Command. У него также должен быть какойнибудь абстрактный метод вроде DoCommand() (какие параметры у него будут, поймешь при реализации, сейчас трудно сказать). Все наследники должны быть сериализуемыми. Отправка команды - это ее сериализация в сетевой поток. Получение - это чтение и десериализация из потока. Полученный System.Object приводится к Command и у него вызвается метод DoCommand().
По-видимому, в качестве параметра придётся передавать весь контекст (набор функций, реализуемых... эм... сервером?)
Цитата: Der Meister
По-видимому, в качестве параметра придётся передавать весь контекст (набор функций, реализуемых... эм... сервером?)
А что тут такого. Замечательная задачка на виртуальные функции и контекст :)
А я и не говорю, что это плохо :) Более того:
Либо
в зависимости от... :)
Код:
Код:
interface IResponseContext
{
void ScreenshotRecieved(ScreenshotResponse response);
}
class ScreenshotResponse : Response
{
public ScreenshotResponse(string hostname, Image screenshot)
: base(hostname)
{
_Screenshot = screenshot;
}
Image _Screenshot;
public Image Screenshot
{
get { return _Screenshot; }
}
public override void Perform(IResponseContext context)
{
context.ScreenshotRecieved(this);
}
}
{
void ScreenshotRecieved(ScreenshotResponse response);
}
class ScreenshotResponse : Response
{
public ScreenshotResponse(string hostname, Image screenshot)
: base(hostname)
{
_Screenshot = screenshot;
}
Image _Screenshot;
public Image Screenshot
{
get { return _Screenshot; }
}
public override void Perform(IResponseContext context)
{
context.ScreenshotRecieved(this);
}
}
Ужас....
1.
1.
Цитата:
А что тут такого. Замечательная задачка на виртуальные функции и контекст
Не согласен......
Мы формируем все функции на клиенте, отдаем их серверу, он выполнет.... Это некрасиво.... Во-первых, увеличивается нагрузка на сеть. Во-вторых, это не логично и не соответствует логике "Клиент-Сервер", "Запрос-Ответ". Да и подумать только с хакерской точки зрения..... Если не устроить авторизацию на сервере (а это нежелательно), то коннекться кто хочешь, диктуй мне функции, я выполню... Хоть комп уничтожу....
Единственный плюс: отлаживать придется фактически только клиент, сервер не нужно....
Я все таки придерживаюсь к своему алгоритму "Запрос-Ответ"... И пока меня не очень устраивает это решение....
2. Не могу полностью разобрать ваш код. Я не очень с интерфейсами, контекстами, абстрактности... ща по-читал и еще собирась читать MSDN.... Но все равно непонимаю я(( Я не профессионал как вы)). Не могли бы вы хорошо прокоментировать код и объяснить общую логику работы?
Пример клиент-серверного приложения (фактически на коленке написаный .NET Remoting), реализующего выполнение команд на сервере.
Архитектура проста. Есть класс CommandBase<T> являющийся базовым для всех команд. Тип-параметр T - это результат работы команды, специфичный для каждого класса команды. T должен быть наследником класса CommandResponse.
Клиент создает подключение к серверу, создает экземпляр команды (в примере это MachineNameCommand) и отправляет его серверу. Сервер выполняет ее и возвращает клиенту результат (экземпляр MachineNameCommandResponse).
З.Ы. Конечно, использование .NET Remoting гораздо предпочтительнее, нежели такие вот выкрутасы.
Архитектура проста. Есть класс CommandBase<T> являющийся базовым для всех команд. Тип-параметр T - это результат работы команды, специфичный для каждого класса команды. T должен быть наследником класса CommandResponse.
Клиент создает подключение к серверу, создает экземпляр команды (в примере это MachineNameCommand) и отправляет его серверу. Сервер выполняет ее и возвращает клиенту результат (экземпляр MachineNameCommandResponse).
З.Ы. Конечно, использование .NET Remoting гораздо предпочтительнее, нежели такие вот выкрутасы.