Программное обеспечение Travelling. Это - понятие?
Я хотел бы спросить, существовал ли там программа, которые были предназначены для перемещения (например, после некоторых физических сил) через планету, возможно заняв и освободив вычислительные ресурсы/узлы. Буквально это означает, что некоторая агентная система просто регулярно изменяется, это - местоположение и (неизбежно в некоторой степени) конфигурация.
Пример был бы: предположите, что у Вас есть внешние датчики, и свободные компьютеры - узлы - через пространство; имело бы смысл самокопировать агенты для следования за инициализаторами от датчиков, но таким строгим способом, что вычисление только локализуется в том, где физический бизнес продолжается.
Я хочу подчеркнуть, что этот вопрос только для 'теоретической' забавы, вызовите, я не вижу практических преимуществ упомянутых ограничений кроме оптимизации 'устаревших' (outplaced?) распоряжение агента. Но возможно это могло иметь некоторый интерес.Спасибо!
Править: Очевидно, что вирус соответствует примеру, хотя удаление таких агентов редко вызывает беспокойство разработчиков. Более точно я интересуюсь программным обеспечением 'перемещения' - то есть, когда количество (или по крайней мере заказывают) агентов является довольно постоянным, и это - просто целая система, кто перемещается.
7 ответов
Я думаю, то, что вы ищете, называется Мобильные агенты .
Кстати: Я не верю, что вирус подходит. Одной из определяющих характеристик вируса является то, что он не может путешествовать сам по себе, а его распространение зависит от человека-пользователя. Однако Черви подойдут.
Да, если у вас есть обрабатывающая сеть доставки по всему миру и какой-то вид миграции сценария, вы можете войти в систему и перенести сценарий на ближайший к вам узел на основе какой-то геолокации.
Может быть, мастер ботнета близок к тому, что вы ищете? Очевидно, очень похоже на «вирусный» ответ выше: разница в том, что, хотя вирусы обычно «размножаются, распространяются, делают заранее запрограммированные неудобства», ботнет - это скорее «взять под контроль вашу машину на будущее, обычно гнусно, но динамическая цель ». Я думаю, что хосты (ваш «агент») тоже могут легко измениться с помощью ботнета.
Исследовательское сообщество в области универсальных вычислений много работает над подобными проблемами.
Например, если вы работаете с документом, он отображается с определенной модальностью взаимодействия в зависимости от устройств вокруг вас. Если вы общаетесь, то же самое. Вы можете возразить, что многие приложения для определения местоположения делают нечто подобное. Министерство обороны спонсировало некоторые исследования контекстно-зависимых автоматизированных помощников и т. Д.
Если мы предположим глобальное распределенное «облако», то место, где на самом деле происходят вычисления, будет для вас неизвестным и прозрачным. Все, что имеет значение, - это контекст. Учитывая, что устройства с поддержкой GPS становятся повсеместными, а обработка видео становится дешевле (моя камера за 50 долларов может распознавать лица), качество контекста, безусловно, повышается. В этом смысле многие программы уже воплощают то видение, которое вы описываете.
Все, что может быть хорошо сделано с помощью движущейся программы, похоже, может быть сделано лучше с помощью широко распространенной.
Я никогда не работал с ним сам, но язык программирования Obliq , похоже, приспособлен для такого рода вычислений. От Obliq paper (страница 12), на который есть ссылка на этой веб-странице:
Obliq обращается к очень динамичной форме распределенное программирование, где объекты может перенаправить свое поведение на сети, и где вычисления могут перемещаться между сайтами сети.
Это, возможно, косвенно, один из постулатов Jini. В данном случае, возможно, речь идет о загрузке драйверов. Но поскольку система основана на Java, концепция переносимого кода, переходящего с устройства на устройство, является одной из основных философий системы.
Итак, с этой целью этот код не "перемещается" как таковой, а скорее копируется. Он не "покидает" сервер.
Но вы можете видеть, в частности на Java, что если начать с пустой JVM и какой-то оболочки, то будет довольно просто заставить код "перемещаться" из одной JVM в другую.
Вы можете представить себе этот процесс следующим образом.
1) В системе А запущено приложение, с состоянием и локальными классами. 2) В системе B запущена "оболочка переноса". 3) A хочет перенести приложение на B. 4) A приостанавливает приложение и сериализует его состояние, это может быть просто использование стандартной сериализации объектов Java. Этот сериализованный объект имеет метод "restart". 5) B устанавливает ClassLoader, который ссылается на классы в системе A. Этот загрузчик классов будет копировать классы по запросу из A в B, затем он может хранить их локально. 6) A отправляет сериализованное состояние приложения в B, который де-сериализует его. 7) ClassLoader на B начинает перетягивать файлы классов из A, по мере десериализации приложения. 8) Когда объект десериализован, B вызывает метод "restart", и приложение продолжает работать. 9) A "забывает" о приложении, и B продолжает работать отдельно от A.
Очевидно, что это наивно и чревато потенциальными проблемами.
Но вы можете увидеть, как, особенно на виртуальной машине, может работать нечто подобное.
Современные архитектуры виртуальных машин работают над этим процессом, и на самом деле это процесс создания моментальных снимков работающих виртуальных машин, перемещения образов на другие машины и их запуска. Основы ВМ делают это "легким".
Пример Java - это просто то, с чем вы можете поиграть, не становясь инженером по виртуализации.