Progress - Week 1

Forums:

This week I have the Master Server created.

Along with that I have the IncomingSubServerPeer which is what we will use to communicate with each sub server.

I created a SubServerCollection class which will keep track of which server is currently the chat server and login server in addition to all region servers. In addition to not only keeping track of which server this is, if the server disconnects for any reason we look for a backup and get it in place.

A SubServerType class was created as a Flag to tell what features a server supports. This helps us determine if a server is setup to only be a chat or login server or any combination of all 3 types. This means that our sub server can have the code for all 3 types, but will only operate on the types it is told to handle at start up.

I will continue to update this post as i complete things for this week.

lazalong's picture

Some questions:

1. You will probably do it later but just in case I suggest we create a Common project which will contain ErrorCode and others codes. In my last project I used it to put all base GameObjects that were common to both server and clients.

2. You have a MasterServerSettings.Designer.cs this is a Microsoft only feature. Shouldn't we try to stick with plain C# as much as possible in case we want to deploy on a -future- non Windows server. (Granted I am also a bit paranoid and don't like that the settings file has "http://schemas.microsoft.com/VisualStudio/2004/01/settings" in it which means MS gets a tick each time I launch my application)

3. In SubServerCollection I might not have fully understood what you are trying to do. But couldn't it be possible that if you add a peer a second time you will remove it (in the trygetvalue part) but might not add it again because either ChatServer or LoginServer is still not null. If you remove it you should imo test those two properties and set them to null if it is the same guid. As you do in OnDisconnect.

4. The Guid id = (Guid)gameServerPeer.ServerId.Value; should be in the lock

5. Personally I will keep for testing the if (!ServerId.HasValue) in IncomingSubServerPeer::OnEvent.
But I will remove it later as this test for each events seems wasteful to me.

1) I will be making a common project. It will be common between the master server and the sub server projects. I think. We'll see as I get moving down the line.

2) I will be sticking with the settings file for now. Photon has stated that any attempts to make a Linux version are on hold for now because of the number of issues they have run into with getting it stable and ported over due to their work on the Photon Unity Networking. Again, you don't have to follow this route, you could easily build your own settings or even just a hard coded set of values. It is all a matter of making use of the system you will be coding against.

3) Ah, correct, I will need to make that modification.

4) There is no need for it to be inside the lock. The value isn't being updated as we already do a null check, it's a read only and not updated. We additionally do a check in the lock to make sure it hasn't been removed before we get a change to remove it.

5) That's fine. I will leave it in just in case someone tries to hack the master server by connecting on that port and trying to flood events through the system.

lazalong's picture

5) That's fine. I will leave it in just in case someone tries to hack the master server by connecting on that port and trying to flood events through the system.

Euhh... Either I didn't sleep enough or this test doesn't test the incoming event but the receiving server instance. If you reach this method the RegisterSubServer instance was already registered with HandleRegisterGameServerRequest(). So if you really want to test the subserver legitimacy you must not register it in the first place. For example if the value ServerId is null or perhaps better use a "secret guid algo" (i.e. only accept server with guids from a defined list or guid that are divisible by 7).

And/or test the request in MasterServer::IsGameServerPeer() if it comes from legitimate IPs - I mean we are managing all the subservers so we know the IPs.

Its been a rough weekend. Haven't done much programming because I twisted my ankle doing Martial Arts and had to have it elevated all weekend. Its almost normal today, tomorrow I hope to tackle the sub server code and get at least one to connect. While I was resting, I wrote up some of the messages I expect to pass back and forth and how I expect to keep track of which clients are connected to which master server.

lazalong's picture

Ouch... I hope you will be fine. My little boys are doing Aikido since 2 months :)

Btw in your last post you wondered if you can still use an IOperationHandler well you can you just need to register it in a Peer with Peer.SetCurrentOperationHandler. One thing you must be careful is that operation must have the correct signature:
public OperationResponse OperationLogin(PeerBase peer, OperationRequest request)

I lost a few hours because I didn't find right away that is you have Peer instead of PeerBase the operation isn't registered!

Ah, makes sense they would update that to use the same interface. Thanks for the tip.

Also, I'm sure I'll be fine. I've had worse ;)

Hey Dragagon, I just started a new Photon project and been following your tutorials here, I was wondering if there was any way you could make the old 2.0 source code available for reference, that would really help me a lot!

Thank you so much :)

Its still available. If you go to the git hub repository, under the main tab buttons you will see a "Branches" button, if you select that and change it to Photon2.6 instead of master it has the old code saved for all time.

Keep up the good work!

I have been following this for a while now, and it is looking real good.