Как создать мини-сеть небольших программ, подающих друг друга данные?

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

В DES вы фактически не выполняете работу каждого узла, а просто моделируете, сколько времени потребуется каждому узлу, чтобы выполнить эту работу. сделанный. Вы можете использовать приоритетную очередь для отслеживания входящей и исходящей работы, а также настроить систему для отслеживания размера очереди глобально и для каждого узла.

Возможно, если вы предоставите более подробную информацию о том, что вы пытаетесь сделать выполнить, мы можем дать более конкретные рекомендации.

Изменить: Python имеет встроенную очередь приоритетов в модуле heapq , см. http://docs.python.org/ библиотека / heapq.html .

Вот как создать базовую программу клиент / сервер: http://wdvl.internet.com/Authoring/python/client/watts06152009.html

Для передачи данных от одного к другому я бы рекомендовал JSON , самый простой формат когда-либо. Отметьте simplejson, если хотите реализовать его на python: http://pypi.python.org/pypi/simplejson/

Мне нравятся предложения @ DigitalRoss и dcrosta о дискретно-четном моделировании, и я хотел бы отметить, что модуль sched в стандартной библиотеке Python - это именно то, что вам нужно ядро ​​такой системы (не нужно перестраивать ядро ​​поверх heapq или иначе). Вам просто нужно инициализировать экземпляр sched.scheduler вместо обычных time.time и time.sleep , передав ему два вызываемых объекта, которые имитировать течение времени.

Например:

class FakeTime(object):
  def __init__(self, start=0.0):
    self.now = start
  def time(self):
    return self.now
  def sleep(self, delay):
    self.now += delay

mytimer = FakeTime()

и использовать s = sched.scheduler (mytimer.time, mytimer.sleep) для создания экземпляра планировщика.

На ум приходят две вещи:

1- Вы можете написать один или несколько демонов с помощью Twisted Python. (Имейте в виду, что twisted может показаться немного сложным, поскольку это асинхронная система, управляемая событиями). Каждый демон может связываться с портом и делать себя доступным другим демонам. В качестве альтернативы, вы можете просто запускать все в рамках одного демона и просто запускать каждый «процесс», который вы запускаете с помощью сценария, с разным интервалом ... и также общаться друг с другом через связанные порты.

2- Вы можете использовать одно событие управляемое ядро ​​- их несколько - и просто разветвляйте связку процессов или потоков для каждой задачи.

Изучите NetworkX , библиотеку Python для создания и управления сетями . Изменить: Внимание, рядом / связанное с NetworkX, а также размещенное в Los Alamos NL, это PyGraphviz, утилита для отображения графиков. Спасибо las3jrock за указание на то, что у меня изначально была неправильная ссылка.

Вы можете использовать NetworkX как есть, или черпать вдохновение из этой библиотеки (я бы не стал беспокоить, что в этой библиотеке действительно есть «все графы», которые кажутся (необходим для моделирования сети.) В любом случае, этот тип создания графа и манипуляции с ним позволит вам представить (и увеличить / уменьшить / развить) сеть.

С одним централизованным объектом / службой, основанным на библиотеке графов, как уже упоминалось, вам останется создать один (или несколько) классов для представления поведения сетевых узлов.

Затем, в зависимости от ваших потребностей, и если сеть относительно мала, сетевые узлы можно эффективно «отпустить» и запустить внутри потоков . В качестве альтернативы (и этим часто легко управлять для моделирования) может быть централизованный метод, который выполняет итерацию по узлам и вызывает их методы «do_it» , когда это необходимо. Если «частота обновления» такого централизованного контроллера достаточно высока, часы реального времени на уровне узлов могут использоваться для определения того, когда должно запускаться конкретное поведение узла. Это моделирование может управляться событиями или просто опрашиваться (опять же, если период обновления достаточно мал относительно базовой единицы времени часов).

Централизованная «карта» сети будет предлагать различные связанные с сетью примитивы , необходимые сетевым узлам для выполнения своей «работы» (что бы это ни было). Другими словами, узлы могут запрашивать у «карты» список своих прямых соседей, каталог всей сети, маршруты (и их стоимость) к любому данному узлу и т. Д.

В качестве альтернативы, структура сети может быть распределена по узлам самой сети , а-ля Интернет. Этот децентрализованный подход имеет несколько преимуществ, но он подразумевает добавление логики и данных к узлам, поэтому они реализуют эквивалент DNS и маршрутизации. Этот подход также имеет недостаток , состоящий в том, что значительный объем трафика между узлами должен быть связан с обнаружением и поддержанием топологии сети, а не с какой-либо семантикой связи / обмена, которую сеть предназначена для эмуляции. . Короче говоря, я бы не стал предлагать использовать этот децентрализованный подход, если только рассматриваемое моделирование не было направлено на изучение самих протоколов таких распределенных систем управления сетью.

Изменить:

Подход DES, предложенный в нескольких ответах, безусловно, касается симуляция часть вопроса. Если часть вопроса сеть важна, реализация виртуальной сети на основе сильной библиотеки графов будет важной частью решения.

Просто используйте Stackless Python, создайте тасклеты, соедините их с каналами, и все будет работать. Это очень просто.

Это то, что Stackless делает очень хорошо.

Кроме того, вы можете использовать генераторы / сопрограммы.

Интересные ссылки:

http://www.python.org / dev / peps / pep-0342 /

Новые пользователи могут размещать только 1 гиперссылку ... вот и другая

'/'.join(['http:/', 'us.pycon.org', '2009', 'tutorials', 'schedule', '1PM6/'])