Best way to send events in time intervals?

Sergiy

Hi

I am thinking of sending some events to large (2000 +) peers. Events should be sent in regular time intervals. Peers should receive events according to their subscription. My options are:

1. In lobby maintain a big list of subscriptions (which peer is subscribed to what kind of event) and a list of events that should be filtered. On each time interval then filter events and send to group of peers that with according subscription. Advantages: serialize once - send to many, disadvantages - lobby needs time to filter events/peers and subscription list is big - around 100 different variants

2. make lobby publish every event to peer objects. Each peer checks whether this event is subscribed or not and, if subscribed, adds to its local list of events.Then on a time interval each peer will send its own list of events to client. advantages - no filtering so it's fast, because each peer already knows what to send to client. disadvantages - on each timer event there would be a peak in network traffic because all events will be sent at once.

3. same as item 2, but each peer has its own timer. it has only one disadvantage - 2000+ timers . However, each peer has a RequestFiber object and RequestFiber has a ScheduleOnInterval method. If i use this method will it be the same as creating 2000+ timers?

What can you suggest?
thanks

Philip

Hi sergiy,

I can give you an answer to your "ScheduleOnInterval" question: internally it would create the 2000+ timers the advantage would be that it does already implement all the plumbing to execute on the fiber thread so you don't have to worry about multithreading issues.

To your design question - you already mention most of the pros and cons. And I can another couple of thoughts ...

pro in 1) - not only is it serialize once its also - less memory intensive assuming you use the Broadcast(peerlist, message) method. We noticed a good performance boost when we started to use Broadcasting in our Rooms.

possible pro in 2) - if your events are small you could pool them together and send them in bigger chunks.
Notice I say "bigger chunks" - as a "really-big-chunk" has some more overhead on the transport level. (assuming you are using udp).

You could have a look to ExitGames.Concurrency.Channels (ExitGamesLib) which is a pub/sub technology that could help you - it works well with fibers. Setting up the pub/sub system by letting peers subscribe to channels and your lobby publish into channels. You can see how it is used in the MMO sample.

That would be a simple implementation of 1. Because the "filtering" isn't really much work using this pattern - my guess would be - that If you see performance issues moving from that design to this:

a) replace the channels by broadcasting objects (each with a fiber), where your peers subscribe/unsubscribe to it in a similar way they do to channels - only that it does the broadcast.
or
b) collect event's in your peers and send them out in bigger-chunks

Its an interesting design question - where you probably will have to do some proof of concept and try out what best works for you.

BTW: a) won't maintain the order over broadcasting objects - it will maintain order per broadcasting object.

BUT with out knowing more on the nature of your events its really hard to give more concrete advice on the architecture
- what is the source of your events? is it timer based? Or are they triggered by other means - like user joined room.
- if the event-source is timer based - could you create several timers for group of events?
- how important is the order in which they are received? would it keep order on a per event-type basis be enough?
- do the peer subscriptions change often?

Sergiy

Thanks Philip

The my goal is to send to a large number of clients information about matches in lobby according to a client-chosen filter. Client may change its filter freely, e.g. move to another room, game type, etc.

Digging into RetLang sources, i found out that Schedule() method creates a System.Threading.Timer object. So i decided not to use fiber's scheduler

I made it in following way:
1. Each peer is subscribed to a channel in lobby, Each peer maintains its filter and the list of matchinfo objects
2. when match status changes, lobby broadcasts the matchinfo via channel
3. each peer will check the matchinfo against its filter and, if it suites him, adds to own list
4. on timer, lobby broadcasts 'send' command to peers
5. each peer decides, based on its internal state-based algorithm, whether it should send list of matchinfos to client, or wait for next 'send' command

Looks like that's the way you suggested

This way, i avoided the creation of many timers, but still looking for some way to use Broadcast(peerlist, message)

chvetsov

This way, i avoided the creation of many timers, but still looking for some way to use Broadcast(peerlist, message)

May be i missed something, why is it not possible for you just maintain lists of peers during subscribe/unsubscribe process?

Sergiy

Well, it is certainly possible, but please consider following:

1. Filters are nested. I mean peer can be subscribed to category1, subcategory 3, subsubcategory 2 or to category 1, subcategory 2, all subsubcategories, etc. There are about 30 possible combinations and so 30 lists should be created.
2. Events are of several types - match created, match started, match finished, etc. In order to send them all at once, peers should be divided not by filters only but also by event types. That gives us another bunch of lists.
3. There should be some logic that maintains all this stuff and tries to avoid network peaks by remembering which events was sent to which lists / peers.