Engine.broadcast behaviour

[zigster64]

Hi, nice lib.

With the broadcast behaviour (not implemented yet ?)

Are we looking at sending that msg to all actors, or will there be a actor.subscribe() type of function to limit who receives various broadcasts

Thinking of the scenario where there are a very large number of actors, with only a small subset interested in certain broadcasted events

…..

Secondary question with broadcasts - consider the scenario where there are many “games” running, each game with many players, each player controlling many actors, and each actor subscribed to a subset of broadcast events

The “event message” could then be a complex struct such as

{
game_id: int,
player_id: int,
… other fields
}

Imagine an actor could subscribe to …

• all messages for a given game_id, any player_id
• only messages for a match on both game_id and player_id

This is already possible using a single message_type .. but for ergonomics it might be interesting to allow complex matching logic for subscriptions.

Performance wise - the match has to be executed at some point in the flow, so it’s just as much work doing it in the actor code as it would be doing it in the engine. Just an ergonomic nicety I think

Thoughts ?

[Thomvanoorschot]

Hi, thanks!

I am still figuring some of the things out as I go. Not sure how exactly I want to tackle a couple of things yet. I am mainly creating this framework for facilitate my other repo, Zigma. In the Zigma repo I already have a pub/sub implementation where an actor sends a "Subscribe" message after which the receiving actors adds the actor_id from the envelope to it's list.

I am debating moving this logic to the framework. I need to think of a clever way of being able to configure what the broadcast logic entails. You can find a simple example in the orderbook_actor in my Zigma project: https://github.com/Thomvanoorschot/zigma

My initial idea was that when registering an actor to the framework it would update a mapping of which actors are interested in which type of messages.

I have recently changed the way messages work. It used to be that the Envelope had a union type on which I could match, but this brought up some "coupling" issues. I want the actors to be able to send messages to each other over a network connection. This means all messages need to be passed as serialised bytes. I am trying out using protobuf which has a way of multiplexing by default by using the oneof. This way I leave it up to the user of the framework to describe how and if they want to match on types of messages.

All of this is very much still up for change if deemed better. Feel free to pitch in with ideas!

Update:

I have started on an example implementation and will let you know when it's presentable

[zigster64]

Brilliant thanks

Having a look through zigma, I can see (I think) that you have actors subbing to other actors, and managing it that way. That works for me.

My use case I have in mind may be a bit different - very early days yet, so when I get some clear time, will dive in and just hack together some rough ideas. Might be dead end, might reveal some useful patterns.

Really like where this is going. I see you have a strong go background (me too), only dabbled a bit with Erlang and pony. Yet to do anything serious with actors.

Fun !

[Thomvanoorschot]

I've moved the pub/sub functionality from my Zigma repo to the framework. It's pretty broad in how it can be used right now, especially when paired with proto encoded structs sent as a payload.

I am open for feedback of course and I doubt this is going to be the final version.

I'm hesitant to add specific logic to the framework which would prevent the user from choosing what kind of messages they want to send. Any logic that filters based on the payload is going to be challenging to keep generic.

Hope this helps you!

[zigster64]

Perfect !

Subscribe to actor
Then topics per actor, where topic can be a structured type.

That’s a great generic interface with ample room for fine tuning

Bit slow on my side - recovering from illness still :( excited to jump in soon