Надо передать код по сети, и выполнить его на удаленной машине.
Решение должно быть оформлено в виде двух библиотек — одна для передающей стороны, другая для принимающей.
Принимающая сторона получает некоторый код, сжимает его, сериализует и возвращает массив byte[].
Пользовательский код по некоторому протоколу передает его на принимающую сторону.
Принимающая сторона получает массив byte[], преобразует его в вид пригодный для исполнения и выполняет.
Требования:
Минимальный размер передаваемых данных — единицы килобайт с учетом сжатия (скорей всего System.IO.Compression).
Минимум зависимостей на принимающей стороне. Желательно ограничиться .NET 2.0, размер кода со всеми зависимостями не более 500-600Кб.
Под "кодом" следует понимать нечто, что можно будет выполнить на удаленной стороне, обладающее произвольной (неограниченной) функциональностью. Это может быть исходник на C#, скомпилированная сборка (.dll), IL-код метода (хотя в 1 метод много не сделает), etc.
Сложность реализации на передающей стороне не ограничена.
Сетевой протокол задается извне и может быть произвольным. Дополнительные каналы передачи использовать нельзя.
Способы решения:
1. Передавать сборку (.dll).
Передаваемый код можно писать на любом языке. Простая реализация на принимающей и передающей стороне.
Однако, даже если передавать только секцию кода, то все равно она будет раз в 5 больше чем исходник.
Очевидно что одна строчка кода ЯВУ
Console.WriteLine("q")
компилируется в несколько инструкций MSIL и кучу метаданных.
2. Передавать исходник.
На принимающей стороне есть компилятор C#, встроенный в .NET, с его помощью можно скомпилировать исходник и потом запустить из памяти.
Однако исходник содержит большое количество избыточной информации — пробелы, длинные имена переменных. Отчасти с этим справится сжатие, но лучше написать обфускатор, который убирал бы пробелы и переименовывал переменные, имена методов и типов.
3. Передавать CodeDom.
Если язык С# — то нужен парсер, т.к. у CSharpCodeProvider не реализован метод Parse.
Лучше парсить исходник, выкидывать из него лишнюю информацию, передавать свой AST, и на принимающей стороне преобразовывать его в CodeDom
Если язык не С# — то надо включить в зависимости принимающей стороны компилятор и рантайм. Например для Boo это будет ~1Мб, что многовато.
4. Передавать IL методов.
Это несколько ограничивает удобство написания кода, надо дизассемблировать и обрабатывать IL-код методов. Слишком сложно.
In Zen We Trust
Re: Передача кода по сети
От:
Аноним
Дата:
09.08.10 20:20
Оценка:
Здравствуйте, Abyx, Вы писали:
A>Способы решения: A>1. Передавать сборку (.dll). A>Передаваемый код можно писать на любом языке. Простая реализация на принимающей и передающей стороне. A>Однако, даже если передавать только секцию кода, то все равно она будет раз в 5 больше чем исходник. A>Очевидно что одна строчка кода ЯВУ A>Console.WriteLine("q") A>компилируется в несколько инструкций MSIL и кучу метаданных.
Ну и что? А если исходиков десятки мегов? По моему это очень эффективное и простое решение.
A>2. Передавать исходник. A>На принимающей стороне есть компилятор C#, встроенный в .NET, с его помощью можно скомпилировать исходник и потом запустить из памяти. A>Однако исходник содержит большое количество избыточной информации — пробелы, длинные имена переменных. Отчасти с этим справится сжатие, но лучше написать обфускатор, который убирал бы пробелы и переименовывал переменные, имена методов и типов.
Это бузусловно гибко, но компиляция требует времени и соотвествующих библиотек на удаленной стороне
A>3. Передавать CodeDom. A>Если язык С# — то нужен парсер, т.к. у CSharpCodeProvider не реализован метод Parse. A>Лучше парсить исходник, выкидывать из него лишнюю информацию, передавать свой AST, и на принимающей стороне преобразовывать его в CodeDom A>Если язык не С# — то надо включить в зависимости принимающей стороны компилятор и рантайм. Например для Boo это будет ~1Мб, что многовато.
AST надо строить, разбирать и еще экзекьютить, это не простая задача.
A>4. Передавать IL методов. A>Это несколько ограничивает удобство написания кода, надо дизассемблировать и обрабатывать IL-код методов. Слишком сложно.
не для всех языков есть IL, а нужно общее решение.
Здравствуйте, Abyx, Вы писали:
A>Надо передать код по сети, и выполнить его на удаленной машине.
Самое прямое решение это конечно сборка с известным контрактом.
Еще возможные решения:
код на интерпретируемом .net языке (python, ruby, etc). Не требуется создавать отдельную сборку для выполнения, это может быть плюсом. Крайняя простота и прозрачность всех слоев в поддержке и отладке.
сериализация AST (nemerle, boo, expressions in fw4.0). Сравнительно трудоемко, но (вероятно) минимальный объем передаваемой информации и удобство анализа передаваемого кода.
Вобщем задача слишком общая, для выбора нужные более конкретные требования.
Здравствуйте, Аноним, Вы писали: А>Ну и что? А если исходиков десятки мегов? По моему это очень эффективное и простое решение.
я уже писал что речь о килобайтах
А>Это бузусловно гибко, но компиляция требует времени и соотвествующих библиотек на удаленной стороне
я уже писал, компилятор C# встроен в .NET, если там есть .NET — там есть компилятор C#
А>AST надо строить, разбирать и еще экзекьютить, это не простая задача.
экзекьютить не надо, компилятор умеет компилить CodeDom
А>не для всех языков есть IL, а нужно общее решение.
мне нужно решение для .NET, там всегда IL
Здравствуйте, _nn_, Вы писали:
__>Как заметил аноним, что может быть проще чем передать сам бинарник и его же запустить ? __>Тем более когда размер не велик.
если (допустим) мне надо уместить все в 1Кб, бинарник не подойдет
Здравствуйте, Ziaw, Вы писали:
Z> Z> код на интерпретируемом .net языке (python, ruby, etc). Не требуется создавать отдельную сборку для выполнения, это может быть плюсом. Крайняя простота и прозрачность всех слоев в поддержке и отладке. Z> сериализация AST (nemerle, boo, expressions in fw4.0). Сравнительно трудоемко, но (вероятно) минимальный объем передаваемой информации и удобство анализа передаваемого кода. Z>
Z>Вобщем задача слишком общая, для выбора нужные более конкретные требования.
требования вполне конкретные, одно из них — на принимающей стороне нет python, ruby, nemerle, boo, etc, и они там никак не окажутся.
также там скорей всего нет .NET 4.0, зато есть .NET 2.0-3.5
