Как опубликовать большое количество актеров в CAF?

Позвольте мне добавить немного фона. Пара функций _1 _ / _ 2_ выполняет две задачи: соединяет два экземпляра CAF и дает вам дескриптор для связи с удаленным субъектом. Актер, который вы «публикуете» для данного порта, должен действовать как точка входа. Это удобное место встречи, не более того.

Все, что вам нужно для общения между двумя актерами, - это ручка. Конечно, вам нужно как-то выучить новые ручки, если вы хотите поговорить с большим количеством актеров. Функция remote_actor - это просто удобный способ провести встречу между двумя актерами. Однако после того, как вы изучите дескриптор, вы можете свободно передавать его в своей распределенной системе. Дескрипторы акторов прозрачны для сети.

Кроме того, CAF всегда будет поддерживать одиночное TCP-соединение между двумя системами-субъектами. Если вы опубликуете 10 субъектов на хосте A и «подключитесь» ко всем 10 участникам с хоста B через remote_actor, вы увидите, что CAF первоначально откроет 10 соединений (поскольку целевой узел может запускать систему с несколькими участниками), но все соединения, кроме одного, будут закройтесь.

Если вас не волнует рандеву для актеров, предлагаемая _5 _ / _ 6_, вы также можете использовать вместо них middleman::open и middleman::connect. Это позволит соединить только два экземпляра CAF без обмена дескрипторами субъектов. Вместо этого connect вернет node_id в случае успеха. Это все, что вам нужно для некоторых функций. Например, удаленное создание актеров.

Есть ли способ опубликовать одного актора в качестве прокси для всех акторов в системе акторов (желательно без существенной потери производительности)?

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

Рекомендуется написать собственный субъект, который явно моделирует рандеву между несколькими системами, предлагая некоторый словарь сортировки.

Просто для полноты: CAF также имеет механизм реестра. Однако ключи ограничены atom значениями, т. Е. 10 или менее символами. Поскольку реестр является универсальным, в нем также хранится только strong_actor_ptr, а безопасность типов предоставляется вам. Однако, если это все, что вам нужно: вы помещаете дескрипторы в реестр (см. actor_system::registry), а затем получаете доступ к этому реестру удаленно через middleman::remote_lookup (для этого вам нужен только node_id).

Плавное масштабирование с (почти) без ограничений - это альфа и омега

Один из способов, используемых в агент-ориентированных системах (не уверен, что CAF реализовал инструменты для этого) - использовать несколько транспортных классов { inproc:// | ipc:// | tcp:// | .. | vmci:// } и, таким образом, иметь возможность выбирать по мере необходимости.

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

Если CAF не предоставляет _{на данный момент} никаких других транспортных средств, кроме TCP:

тем не менее, можно прибегнуть к шагам и измерениям уровня O / S и использовать возможности модели ISO-OSI до пределов или по мере необходимости:

sudo ip address add 172.16.100.17/24 dev eth0

или лучше сделать дополнительные IP-адреса постоянными, то есть отредактировать файл /etc/network/interfaces (или Ubuntu) и добавить столько строф, чтобы он выглядел так:

iface eth0 inet static
    address 172.16.100.17/24

iface eth0 inet static
    address 172.16.24.11/24

Таким образом, пространство конфигурации может быть расширено для случаев, когда CAF не предоставляет никаких других средств для таких субъектов, кроме упомянутого TCP (адрес: порт #) - транспортного класса.