Login Server - Best Practice

Started by
22 comments, last by KnolanCross 11 years, 6 months ago
hi ruithamus,

I really like the progress and level of execution of your game and the way you try to de-escalate a conflict, but you have a somewhat blind eye on this situation. wink.png

To answer your question in short: take any cheap (web-)server to handle your logins, before the login process will be the bottleneck, you will have mastered a lot of other challenges not yet encountered.

The long answer is, that you have some ambitious goals, which reaches too far into the future. I got this mood from time to time myself, so I feel with you smile.png But the truth is, that you don't have a game yet (you will see that in a few years from now on). It is a common law of software development, that 95% of the software is done in 5% of the time, but the last 5% of the software needs 95% of the development time. The feeling that a software is almost done is somewhat delusive smile.png

Therefore it is always dangerous to solve problems ahead of time, it binds resources otherwise good invested in other parts and most often don't solve a problem at all, because there will be no problem.

The hard part about developing a game is, to overcome the impulse to overhaul/refactor/extend the game and go back to the existing base and polish it. This needs a lot of discipline and many hobby software project breaks at this point, because they sprint through development, making great progress and adding new feature to stop once the actual work starts by polishing the game and adding content.biggrin.png
Advertisement

First off, your initial question was "is this worth the effort". People respond to your question to their best knowledge and you dismiss this as "not being helpful". Second thing - this is public forum and you don't "own" this thread, you merely ask people for help/opinion and they're entitled to answer whatever they like as long as it follows the forum rules.


Anything can be subjective and open to interpretation. You can define what I asked as something, and others can define what I ask as something else. When I asked if it is worth the effort I didnt need people to say "spend your time on other things in your development. Make a game first" on the other hand if somebody would have said ( which they did later on ) "What you are talking about is overkill, perhaps you might want to lower your goal since such a request can be handled with far less effort. So in short, what you are speaking of is not worth it. Example here, blah blah blah"

While I appreciate people "looking out for me" I think they do not understand the scope of the situation and I fail to see the need to define that before any request is made. Again, I understand that the posts made were with good intention but I am not some 13 year old would be coder. I am a designer looking to gather information and help my coders when they are ready to tackle the issue. This means that I have all the time in the world to sit here and discuss this stuff. Furthermore, is that not what a forum is about, Discussion? Dismissing a question because the replier feels the poster is not "ready" seems kinda counter intuitive to the overall goal of the forum.

Lastly, while I do not own or run this forum, I am a poster and have the right to try and direct the conversation to the purpose of the OP. Allowing the thread to derail and become a flame war because I am doing something that others feel is out of order seems rather silly. I did not name call or bash anybody or belittle them. I did however provide information as to what I was attempting to learn in a blind hope to redirect the conversation to on topic posts. Feel free to post whatever you like...


Bashing every poster you don't agree with is hardly a good way to get more help here.


I never bashed anybody, i simply expressed why they were focusing on the wrong part of what I as attempting to do here.


And to be honest, they totally have the point. If you ask what you ask you clearly have no idea what you're talking about and they're being helpful trying to convince you that you picked the wrong route there. Seriously, login server with 10k login requests per second? You probably don't want to hear my opinion, but you already wasted too much time arguing here with people that know way more than you and are trying to show you a better approach. But you obviously know everything already, just not how to create the perfect login server?


I never suggested that I know everything. As for time wasted, I would argue otherwise. HPlus added some very good information after the fact which has sparked some research into that area. Again this goes back to focusing on the OP's point. While I may not have clearly defined it ( because of my lack of knowledge ) I was attempting to learn some information on the best practices for making a login server. No where in my post did I ask "should i make a login server before or after the game is made". So opinions such as that which do not follow up with the original information I asked for seem rather... odd to post about. Hell, I would like it if people would have posted their opinion about not doing it till the game is fully done and THEN telling me how they might go about making a login server. ( which Hplus did in a later post and if you will read, i was very happy with )

Your tone in itself can be taken as hostile. Why such an emotion seems to be created god only knows but the goal here was not to piss people off, rather it was to learn how to setup and manage an authentication server. If you dont like that idea say so but dont expect me to take your words and praise them as if they came from god himself. My goal is to learn how to make an authentication server... if I wanted to learn how to create a game I would have made a post that asked "How do I create a game" and it wouldnt be placed in this section of the forum.


I really like the progress and level of execution of your game and the way you try to de-escalate a conflict, but you have a somewhat blind eye on this situation. Posted Image


Perhaps


To answer your question in short: take any cheap (web-)server to handle your logins, before the login process will be the bottleneck, you will have mastered a lot of other challenges not yet encountered.


While... I am not sure that fully answers it, it certainly does help. I have a dedicated server based out of LA, Chicago, and Dallas... all of which are more than capable of handling thousands of requests a second. None of them are currently dealing with that much of a load and none them of them deal with authentication... so I was curious if it was worth the effort to waste 10 days building a site that would track traffic use and spread that page out to have many people bog it down. The purpose of that experiment would be two fold as it would help for us to see how much traffic could be generated and it could help us to determine the overall load that an authentication server would have to handle.

You may be asking, why do you need that right now? And while you all make valid arguments for having a game before such a thing is looked into... I am not certain you understand the situation I am in. If you will notice on all of my posts anywhere on this forum I very rarely share code. This is not because I am a prude but rather because I dont know how it works! I am a designer and a graphics artist by trade. I am good at conveying a message and painting pictures for people. I do not speak the beep boop language and I find it difficult to do so some times. My coders ( 3 of them ) are busy cracking away at he core elements of the game. Would it not be smart for me to look around and invest time in research for future development projects that will arise? Seems like the best thing I could be doing is making sure that all of the coders have the tools and resources they need for when the task will come.

So, i would post here, get some information, do some research, and then go and log that information and research in our Task tracking program. ( which we have ) and assign it to the proper people for when they are ready to tackle it. All the information they would need to code is collected and ready for them. Seems like that would be a best practice to me.

That said, we have everything that minecraft has and then some. We have everything from block creation to destruction as well as the ability to create your own via XML files. We have complex crafting and item augmentation ( like an enchantment system ). We have models and model placement in the world. As of right now we are more or less working on polishing the game with shaders and game content. We are well past the stage of making the engine. So, it would seem to me that I already have a very established setup.

The issue that we found as a dev team ( which I am not sure needed to be brought up by why not since this topic seems to be fully derailed ) was that our initial design was to create the game for single player use and add in multiplayer later. ( the coders wanted to do it that way while I suggested they code from a multiplayer mindset and make single player a server of 1 of 1 ) Now we are 8 months into development and we just took a 2 week setback because we have to rework ALL of our code to work with a server/client setup. Imagine if we would have looked ahead to the future and planned for such a thing before just running in and going all willy nilly. Some times that has to be done and some times it is good to look ahead a bit and plan for such things. I would argue that is the goal of the project lead.

Anyway, I dont want to waste further time dealing with something as fundamental as when we should or should not tackle things. That honestly should be saved for another thread in another section. I appreciate the concern you all have... honestly I do. It means that you value my time and because of that I want to ensure you know that I am not upset or hurt that you would post your wisdom. I was simply looking for an answer on the validity of creating an authentication server and testing out the load ( however blind my scope might have been ). Again, I thank you all for taking the time to post on this thread and share your thoughts. Please do not feel that I dont appreciate that, even if they were in direct opposition of my personal goals/thoughts.

Again thank you for your time and consideration on this thread. I apologize for any annoyance I have caused as that certainly was not my intent.
This has already been mentioned, but I would say the login server in most games will be the least of your issues.

In most games, your login experience is only say 5% of the time players are using your application. The other 95% they are actually in the game. And then on top of that, while in the game, the load on the CPU + network are probably far heavier. In the login server, that's probably just a couple of sockets and database calls to determine which game server to route the player to etc. However, playing the game could easily be in the range of 10 socket exchanges per second to handle position updates, user input, etc. For many games, you'll probably only need a single login server per 100 game servers or so.


Keep in mind, when you see games like WoW or minecraft appear to fail on the login process, that does not mean the problem is necessarily on the login side of things. It more likely is just reflecting that some of the game servers are inoperative.
Well, i am no stranger to networks, however I am a stranger to code in relation to networks.

Often when a site is down it could many things, in the case of servers for wow and other such games, players reclick and reclick to gain access and in a sense are creating a dos attack on the server ( making the problem worse ). There is nothing you can do to fix that except for create a system that could possibly deal with that. ( not saying that I would be able to even do that, just spitballing at this point )

Our setup will require the player to authenticate to a centralized account server, from there you will gain access and that can be handed off to whatever the privately hosted servers are. We are not making an MMO, so that is where the tricky part comes in. Our authentication server will be on the opposite side of where most servers will be hosted ( since they are privately ran ), this creates a unique problem since you need to verify the player is legit and then pass them off back to the server that they are attempting to join. Location may not be as much of an issue as security is. As we all know, increased security creates issues with time and resources which can result in the lockout ( which is my main fear ). My desire is to find out the best practice to handle this. Throw some ideas around and see if people have a better approach than simply setting up a server that passing information along.

Maybe that is just it, that is the only way to do it! I personally do not know as I have never made a game that had to authenticate to a server that was not part of the game server.

Here is an example of what I am saying:
gallery_1_8_78032.jpg
I wouldnt be coming here and asking these things if I did not have a game already in place. [/quote]

That would have been good to put into the question to help focus it. Also, some of the other things in the question were getting in the way of providing the actual answer you were looking for. Here's another way to ask the question, for comparison:

Hi! I already have a game developed, and now I need to figure out how to do login and authentication. I have a central server that verifies users, but actual game servers are hosted by any player on the internet. How should I structure this, and how worried do I need to be about scalability for different levels of sales? (Btw: I plan on selling 10,000 copies in the first six months.)[/quote]

If that had been the question, you would have gotten a different answer. I just want you to realize that communication is a two-way street -- everything may be clear in your mind, but when others don't react the way you expect them to, it's probably more like likely that the problem is with how you present your case, than it is with everyone in the thread trying to be malicious.

The additional bit of information that servers are not trusted (hosted by players) means that you can't JUST use a ticket, because those servers can't be configured with the secret for the hash/HMAC. Instead, you have to provide a second function on the simple server I suggested above: verify a ticket. Given a ticket as argument, it should simply return true or false for whether that ticket is currently valid for the user it claims to be. The flow would then be:

1) player authenticates with the main server, and a ticket is returned (no change here)
2) player connects to player-hosted server, and presents its ticket
3) player-hosted server asks login server for validity of ticket

This means that your login server needs to serve two requests instead of one request for each player that logs in, but the order of magnitude of load is still the same.

Also note that a malicious server could do bad things to a user account if it's allowed to use the ticket to file requests on the user's behalf. If you have important resources guarded by player accounts, this may be a problem. ("Hey, this player is giving all his XP and gold to this other player!") Thus, perhaps the best way to structure that, is to issue TWO tickets; one that says "I am the player" and one that says "I am a server the player is logging in to." For requests like "player A trades resources with player B" you would then require that player A makes the request straight to the server using player A ticket, and player B makes the request straight to the server using player B ticket, and perhaps player-server also makes the request to the server using the player-A-server and player-B-server tickets. That way, you know that both players are desiring to perform the action (because you see each of the player tickets) and that the player-hosted server has said OK to the trade (which enforces some kind of server rule -- but that rule is hackable because the player-hosted servers are hackable.)
enum Bool { True, False, FileNotFound };

Also note that a malicious server could do bad things to a user account if it's allowed to use the ticket to file requests on the user's behalf. If you have important resources guarded by player accounts, this may be a problem. ("Hey, this player is giving all his XP and gold to this other player!") Thus, perhaps the best way to structure that, is to issue TWO tickets; one that says "I am the player" and one that says "I am a server the player is logging in to." For requests like "player A trades resources with player B" you would then require that player A makes the request straight to the server using player A ticket, and player B makes the request straight to the server using player B ticket, and perhaps player-server also makes the request to the server using the player-A-server and player-B-server tickets. That way, you know that both players are desiring to perform the action (because you see each of the player tickets) and that the player-hosted server has said OK to the trade (which enforces some kind of server rule -- but that rule is hackable because the player-hosted servers are hackable.)


The military does this with PKI, a public key which is stored on a physical device ( which in your setup would be the users passwords ) and a private key, given by a CA ( certificate authority ) and checked for reliability. If the user has a private key and a public key is most likely the user. ( loose translation of what you said here, but i think it is more or less the same concept ) Am i right?


If that had been the question, you would have gotten a different answer. I just want you to realize that communication is a two-way street -- everything may be clear in your mind, but when others don't react the way you expect them to, it's probably more like likely that the problem is with how you present your case, than it is with everyone in the thread trying to be malicious.

Perhaps, again I am not familiar with this entire thing so I dont even know what I was really asking. I have an idea and wanted to share it... seemed as though in doing that people were telling me to do something that I had already done. I can agree that maybe I took that personally when I should not have. I am not use to be caught off guard in such a way since I normally have some idea of what I am talking about. Thank you for your patience and understanding.
The military does this with PKI[/quote]

PKIs mean that you can authenticate a particular request as coming from a particular user, and you know it hasn't been tampered with in the middle. This means that each request that comes from a user through a server would have to be forwarded verbatim to the end server by the middle server. I imagine there are simple cases where this is good enough, but in the general case of a distributed system where resources are additionally stored on a central server ("resources" could be things like earned levels, global XP, unlocked doodads, etc) it's not quite the same thing.

Note that not only the military uses a PKI -- HTTPS is also based on a PKI and a chain of trust in certificate signing. TLS, the underlying protocol, can actually also authenticate the user, but most of the time, HTTPS connections only care about using the PKI for authenticating the server.
enum Bool { True, False, FileNotFound };
If I got the idea correct, he meant that each player would have two key, a "login key" and a "transaction key".
In short, if I were a player, my login key would be sent to the private server, but my transaction key would not.

An example:
Say during the game player A wants to sell an item to player B for gold. The private server will then send a request to your main game server saying:
Player A of login key x (the one he received from player A when he logged in the private server) wants to trade his item i with player B of login key y (same logic of the former parenthesis) for g gold pieces.
The main server will open a transaction saving the players in question, the item and the amount of gold.
Player A will send a message to the main server with his "transaction key" - which only he knows - telling the player he wants to trade with, plus the item and the gold amount.
Player B will do the same as player A.
When the main server have received the three messages and all the keys match (as well as the item and gold amounts) the transaction is processed.

This is very different from PKI, under which there is a public key (know by everyone) that is used to encrypt messages and the encrypted messages are only decryptable with the private key.

Currently working on a scene editor for ORX (http://orx-project.org), using kivy (http://kivy.org).


This is very different from PKI, under which there is a public key (know by everyone) that is used to encrypt messages and the encrypted messages are only decryptable with the private key.


Well that is one use of it, you can also use the two key method for verification of a user when accessing sites or resources. To access mypay.dfas.navy.mil you need the public key, saying you have CAC and you need the private key ( your pin ), I was simply trying to related to what his suggestion was.

This topic is closed to new replies.

Advertisement