Как & quot; опубликовать & quot; большое количество актеров в CAF?
Я только что узнал о CAF, C ++ Actor Framework.
Одна вещь, которая удивила меня, это то, что способ сделать актера доступным по сети — это «публиковать» это к конкретный порт TCP.
Это в основном означает, что количество действующих лиц, которые вы можете опубликовать, ограничено количеством имеющихся у вас портов (64 КБ). Поскольку для публикации субъекта требуется как один порт, так и один порт для доступа к удаленному субъекту, я предполагаю, что каждый из двух процессов сможет совместно использовать в лучшем случае около 32 тыс. Актеров каждый, в то время как каждый из них, вероятно, может содержать миллион действующих лиц на обычном сервере. , Это было бы еще хуже, если бы в кластере было, скажем, 10 узлов.
Чтобы сделать публикацию масштабируемой, каждый процесс должен быть открыт только 1 порт, для каждого актера в одной системе, и открыть 1 подключение к каждой действующей системе, к которой они хотят получить доступ.
Есть ли способ опубликовать одного актера как полномочие для всех актеров в системе акторов (желательно без какой-либо значительной потери производительности)?
Решение
Позвольте мне добавить немного фона. middleman::publish/middleman::remote_actor Функциональная пара выполняет две функции: соединяет два экземпляра CAF и дает вам дескриптор для связи с удаленным субъектом. Актер, которого вы «публикуете» для данного порта, должен действовать как точка входа. Это удобная точка встречи, не более того.
Все, что вам нужно для общения двух актеров — это ручка. Конечно, вам нужно как-то выучить новые ручки, если вы хотите поговорить с большим количеством актеров. remote_actor Функция — это просто удобный способ осуществить рандеву между двумя актерами. Однако после того, как вы изучите дескриптор, вы можете свободно передавать его в своей распределенной системе. Дескрипторы актера прозрачны для сети.
Кроме того, CAF всегда будет поддерживать не замужем TCP-соединение между двумя действующими лицами. Если вы опубликуете 10 актеров на хосте A и «подключитесь» ко всем 10 актерам с хоста B через remote_actorвы увидите, что CAF первоначально откроет 10 соединений (потому что целевой узел может запустить систему с несколькими акторами), но все, кроме одного соединения, будут закрыты.
Если вас не волнует свидание для актеров, предложенное publish/remote_actor тогда вы также можете использовать 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 (адрес: порт #) — транспортный класс.