couple of Server questions

mindlube

Hi just a couple of random q's:

1) In the server API, is there no way to enumerate through all the connected peers in the App? If not then I guess we have to maintain a collection of them via PeerBase methods? It's not a big deal, I just wanted to make sure I wasn't overlooking anything.

2) I was doing some stress testing, and the server is great at recovering from over-loading. I guess the Fibers helps with that. Is there any way to see how many operations or events are pending? After I run my C# test client, then kill off the test clients, the server keeps processing operations and events for a long time (until they are all finished). At first I was surprised because the peers were disconnected by then. But I realized it must be because I have reliable set to true, so photon is being diligent I guess. Is Ping usesful for this kind of metric? or is Ping just more like the networking utility "ping"?

[Deleted User]

Hi,

1) Right. You need to extend the server-side code yourself. I would probably create a class that holds a list of all connected peers, and add / remove the peers in your code that overrides ApplicationBase.CreatePeer() and PeerBase.OnDisconnect().

2.) Everything that was enqueued / scheduled on the fiber is executed, yes - no matter if the peer state is actually connected or disconnected. You can add a counter to the fiber if you add this to the Peer's constructor:

[code2=csharp]((PoolFiber)this.RequestFiber).CounterEnqueue = new NumericCounter("EnqueueCounter");
((PoolFiber)this.RequestFiber).CounterDequeue = new NumericCounter("DequeueCounter");[/code2]

And check the number of enqueued items like this:
[code2=csharp]var numberOfItemsInQueue = ((PoolFiber)this.requestFiber).CounterEnqueue.GetNextValue() - ((PoolFiber)this.requestFiber).CounterDequeue.GetNextValue();[/code2]

The application-level ping is executed on the fiber the same way as any other operation, but I don't think that it's useful here.

mindlube

Thanks Nicole, that makes sense

mindlube

re: question 1) have found that ConcurrentDictionary and ConcurrentQueue, etc. are good datastructures for this use case. There can just be a static var in the ApplicationBase subclass, and then all the peer requestFibers can access it at will. This eliminates the bottleneck of having a single fiber in the ApplicationBase, handling all the peer-related data structures. Once I made the data structure thread safe, and moved all the actual work out to peer requestFibers, then the server app performance is better.

Tobias

You still want to minimize access to the Concurrent* data. There are hidden locking mechanisms in those and this means your formerly independent threads might have to wait at certain points. Those might become a bottleneck when there's a lot of activity.

mindlube

Thanks Tobias, that's a good point. It's definitely a trade off. I really wish Photon had a way to lookup a Peer based on a unique id. Such as a playerId. I guess consider this a feature request

use case is an asynchronous turn-based social game. I need to push game event changes to connected peers:

- receive operation request with update
- update in database
- lookup playerIds who are interested/subscribed to the game
- map the playerIds to currently connected Peers ** this is the problematic data structure**
- broadcast the event to that subset of peers

Thanks

mindlube

Speaking of using System.Collections.Concurrent; I have read that .NET 4.5 includes some big improvements to ConcurrentDictionary. In .NET 4 it seems to work fine, but I will take any boost I can get. Can Photon run with .NET 4.5? I wasnt' able to get it to launch by using CLRVersion in the config.

dreamora

.NET 4.5 is CLR4 too.
There are only 2 CLRs in .NET, thats CLR2 and CLR4 (or the old and the new), of which the later is not backward compatible.

By installing .NET 4.5 you overwrite the old .NET 4.0 CLR4 version with the .NET 4.5 CLR4 version and are automatically on it already if you use the CLR4 for photon

mindlube

Ah OK thanks dreamora.