Login Server - Best Practice

If our game is successful we could have upwards to 10,000 requests a second.

Wow.

That's on the same magnitude as the average number of Google searches globally.

Your title mentioned it as a login server. Consider the top-tier Facebook games are just barely hitting 7M Daily users, which averages out to 80 logins per second.

It is highly unlikely you will hit 10,000 login requests per second, EVER.

If instead that is your main game, then supporting 10K simultaneous requests is going to probably have bandwidth --- not server capacity --- as your biggest problem. You'll be looking at multiple fiber connections to handle it.



A well-designed system will accept an arbitrary number of computers. A master system allows an arbitrary number of worker machines that handle the connections and such. A good design allows them to be added and removed from service at any time, so you can scale up your number of servers with ease.

[quote name='riuthamus' timestamp='1349808125' post='4988430']If our game is successful we could have upwards to 10,000 requests a second.

Wow.

That's on the same magnitude as the average number of Google searches globally.

Your title mentioned it as a login server. Consider the top-tier Facebook games are just barely hitting 7M Daily users, which averages out to 80 logins per second.

It is highly unlikely you will hit 10,000 login requests per second, EVER.

If instead that is your main game, then supporting 10K simultaneous requests is going to probably have bandwidth --- not server capacity --- as your biggest problem. You'll be looking at multiple fiber connections to handle it.



A well-designed system will accept an arbitrary number of computers. A master system allows an arbitrary number of worker machines that handle the connections and such. A good design allows them to be added and removed from service at any time, so you can scale up your number of servers with ease.
[/quote]

Well, these are things I do not know... maybe 1000? Users will have to login and authenticate, to do that we need ( should ) have a separate server to manage and maintain that. Once the login is verified the handshake would close and pass on that the login was correct to the client. From there a secure connection would be created to the game and would allow the user to connect to the items/characters they had. My concern is what happened to minecraft and many other mmo's, if we have to many login requests we are more or less making our system ddos'd by the playerbase that will be playing it. Assuming I am able to get 1,000,000 people access to the game ( big goal but it is my goal ) that means we could have lots of requests going to the login server at one time.

Any information on how I could do this or best practices would be great!

I think you're starting in the wrong end. First, you have to make sure that you have a game that's fun, and that people care about. Then, you need to make sure that you know how to add capacity once you have a success. Then, you need to start promoting your game. As your user base grows, you should add capacity to stay at least a few weeks ahead of the curve.

And, if you really worry about this, then develop on a public cloud where you can easily provision hardware you need -- Amazon ECC, Linode, Rackspace, Heroku, or similar. That way, you can start with a micro instance that contains both database and application server and cache (good enough for 10 users per second,) and then grow to a bigger instance once you have users, and then split to multiple instances once you're successful, and only pay for what you use/need.

I think you're starting in the wrong end. First, you have to make sure that you have a game that's fun, and that people care about. Then, you need to make sure that you know how to add capacity once you have a success. Then, you need to start promoting your game. As your user base grows, you should add capacity to stay at least a few weeks ahead of the curve.

While i respect your choice to have an opinion i do not agree with it. If i muddle around without planning for such things and when the time comes I have to rework most of my stuff because I was simply throwing things out there, it would be a huge waste of time. Part of what makes the game fun ( as per what I want to do ) is having 100+ players in a server fighting and going at it. To ensure that happens I need to make an authentication server that doesnt bug out like minecraft does. Players cant access servers with their accounts if the primary authentication system is down because it doesnt handle stuff correctly. Why waste time in later development when I can do so now? That said, i wouldnt spend 500 hours working on a flawless system if the need was not there. Im simply trying to process out what is the best practice for making an authentication server. Not sure your comment supports or helps with that.

And, if you really worry about this, then develop on a public cloud where you can easily provision hardware you need -- Amazon ECC, Linode, Rackspace, Heroku, or similar. That way, you can start with a micro instance that contains both database and application server and cache (good enough for 10 users per second,) and then grow to a bigger instance once you have users, and then split to multiple instances once you're successful, and only pay for what you use/need.

I do own a Linode server already. I have a media temple one, as well as 4 other dedicated servers that can host up to 25 game servers on them each. I have plenty of resources at my disposal ( thanks to my gaming community ). Again, my major point of this post was to detail out the best possible practice for creating such a process. Should the login/authentication server be held on a different machine than the web server? how would you make them interact with one another since it all needs to be linked? Those types of things. I apologize if I did not detail myself better in my original post; thus causing all of this confusion.

I would agree with hplus. Just make the game first. You can develop the game with efficiency and reliability in mind but, once you release the game you can then expand (improve hardware) as the game grows. 10,000 connections per second wont happen overnight.

Or you could look at a whole different approach - use steam (even though they will take a cut), you can develop your dedicated servers that the public will be able to host to verify each player is a valid steam client with a copy of the game (You should be able to do this, if not my bad. I havn't played around with the steamworks API main due to the problem being I havnt released a game on steam yet).

If i muddle around without planning for such things and when the time comes I have to rework most of my stuff because I was simply throwing things out there, it would be a huge waste of time.[/quote]

Wouldn't it be an even huger waste of time to spend time writing support for a game that nobody wants to play? Or spending time optimizing something which won't actually turn out to be a bottleneck in the end?

Part of what makes the game fun ( as per what I want to do ) is having 100+ players in a server fighting and going at it. [/quote]

But that doesn't mean that login servers are a bottleneck at all. A login server needs to verify user name/password, generate a signed ticket with some lifetime, and write an entry into a log file. You can do thousands of that per second on a single virtual instance, and if you have a thousand users per second logging in, you're bigger than any indie game company I know of (except possibly for Steam.)

To ensure that happens I need to make an authentication server that doesnt bug out like minecraft does.[/quote]

I think Minecraft is a phenomenal success and I would have been very proud have I created it. Sure it can be better, but 99.9% of all projects are actually failures. Usually, the problem is that developers spend way too much time building things that don't matter *yet* instead of making sure they figure out what the successful game will look like. Building robust infrastructure as you need it is much easier than building a compelling experience that users want to pay for.

That being said: If you can spend six hours instead of two hours on some task, and the difference is that with the six hours, you solve a problem right, and with two hours, it will fail when you have a hundred users, then spend the six hours. Just don't spend six days if you can unblock the "fun finding" with two hours of work.

If you want to understand load generation, set up a user database in Redis or something. Spin up an Apache or nginx or Node or something. Write a little PHP script or JavaScript or whatever, where all it does is:

0) decode the user name (email?) and password from the request
1) look up the user record based on the user name / email in Redis
2) hash the provided password with a salt
3) compare the password hash with the hash in the user record
4) if mismatch, return error
5) if match, create a ticket consisting of (username:expirytime:hash(username:expirytime:serversecret)) and return success

Now, your client can present the ticket to any server, and it can verify that the user is who he/she says he/she is by simply verifying the hash (all servers should be configured with the same server secret.)

Now, use "ab" or a similar load testing program, running on another machine or two, to generate load for this service, and see how far it goes.

Note that, if average session time is 1 hour, and average login request service time is 10 ms, then you can serve 360,000 simultaneous online users from a single login server, and I'd be quite surprised if the login mechanism described above couldn't be made to run much faster than that.

And, if you're using a simple key/value store for user records, and a simple signed-ticket service for login/authentication, then you can scale horizontally with very little effort -- use consistent hashing for the storage instances, and any HTTP load balancer for the front end. This is a solved problem, and as long as you have a reasonable path towards the scalability you need, you don't actually need to develop and test it until you actually need it. Time is the most precious resource we have, and using it to address the biggest risk first is, IMO, the best use of it.

You are wasting your time, first write a game that demands 10,000 requests per second, and then you will be able to hire a whole team of hplus types to solve all your problems

Or you could look at a whole different approach - use steam (even though they will take a cut), you can develop your dedicated servers that the public will be able to host to verify each player is a valid steam client with a copy of the game (You should be able to do this, if not my bad. I havn't played around with the steamworks API main due to the problem being I havnt released a game on steam yet).

I thought of doing that as well...

I would agree with hplus. Just make the game first. You can develop the game with efficiency and reliability in mind but, once you release the game you can then expand (improve hardware) as the game grows. 10,000 connections per second wont happen overnight.

I think you guys are missing the point. I have a game.... the point now is to work on the connections to enter the game. I wouldnt be coming here and asking these things if I did not have a game already in place. I am looking for ideas on how best to tackle the situation not advice on where to start the game development; while I appreciate the concern, it is more or less pointless to attempt to try and tell me "dont bother with this till much later". I am bothering with it since it is where we are going next. As for 10,000 requests... i have no clue what is or is not a bit amount. I have come to this section looking for knowledge... If this is the improper practice I am sorry for my misunderstanding.

Wouldn't it be an even huger waste of time to spend time writing support for a game that nobody wants to play? Or spending time optimizing something which won't actually turn out to be a bottleneck in the end?

It would be, assuming I had nothing... an assumption that is very much unfounded.

But that doesn't mean that login servers are a bottleneck at all. A login server needs to verify user name/password, generate a signed ticket with some lifetime, and write an entry into a log file. You can do thousands of that per second on a single virtual instance, and if you have a thousand users per second logging in, you're bigger than any indie game company I know of (except possibly for Steam.)

This is good information to have, something that I did not know and something that is important to realize. Scope is the whole point of this and if the scope I was looking at is too grand than I can certainly scale that back a bit. This is constructive information, much more than the "dont bother with this for now" comments.

I think Minecraft is a phenomenal success and I would have been very proud have I created it. Sure it can be better, but 99.9% of all projects are actually failures. Usually, the problem is that developers spend way too much time building things that don't matter *yet* instead of making sure they figure out what the successful game will look like. Building robust infrastructure as you need it is much easier than building a compelling experience that users want to pay for.

That being said: If you can spend six hours instead of two hours on some task, and the difference is that with the six hours, you solve a problem right, and with two hours, it will fail when you have a hundred users, then spend the six hours. Just don't spend six days if you can unblock the "fun finding" with two hours of work.

I never said that minecraft wasnt a success, i said I do not want to fail on the aspect of not being able to login, as they have had that issue on several occasions. The point of this thread is not for me to get advice on what I should be working on. The point of the thread is to get advice on how best to handle a login server. I am not the main coder of my game and because of this I have all the time in the world to waste on asking these questions and learning. Without knowing my development process and my development team such advice seems unfounded and more or less a waste of all of our time. If you have something of value to add to the post please let me know so I can learn and start to do some research. Otherwise, I would very much appreciate the comments about "not a valid use of time" to cease. Part of the development process of any project is research and development.... to get there you have to know how things work and how they are built. That is what I am doing with this thread... finding out the information with the help of people who are, much like yourselves, experienced. Walking through the jungle can be a very dangerous path... but if you have a tour guide they can show you the things you need to know to get through and focus on what you are looking for.

Thus, the creation of this post. Finding those people who know much more about a thing that I have barley scratched the surface on. Again I will stress that I have all the time in the world to be doing this so please indulge me with your comments on how best to approach this, otherwise dont post about how I should or shouldnt handle my time.

If you want to understand load generation, set up a user database in Redis or something. Spin up an Apache or nginx or Node or something. Write a little PHP script or JavaScript or whatever, where all it does is:

0) decode the user name (email?) and password from the request
1) look up the user record based on the user name / email in Redis
2) hash the provided password with a salt
3) compare the password hash with the hash in the user record
4) if mismatch, return error
5) if match, create a ticket consisting of (username:expirytime:hash(username:expirytime:serversecret)) and return success

Now, your client can present the ticket to any server, and it can verify that the user is who he/she says he/she is by simply verifying the hash (all servers should be configured with the same server secret.)

Now, use "ab" or a similar load testing program, running on another machine or two, to generate load for this service, and see how far it goes.

Note that, if average session time is 1 hour, and average login request service time is 10 ms, then you can serve 360,000 simultaneous online users from a single login server, and I'd be quite surprised if the login mechanism described above couldn't be made to run much faster than that.

And, if you're using a simple key/value store for user records, and a simple signed-ticket service for login/authentication, then you can scale horizontally with very little effort -- use consistent hashing for the storage instances, and any HTTP load balancer for the front end. This is a solved problem, and as long as you have a reasonable path towards the scalability you need, you don't actually need to develop and test it until you actually need it. Time is the most precious resource we have, and using it to address the biggest risk first is, IMO, the best use of it.

This is exactly what I like to read as it is informative and supports the idea you wish to express. Informative and it shares your point of.... its not needed right now in a way that seems less hostile. Thank you for this information as it will certainly help in me finding the path I am searching for.

You are wasting your time, first write a game that demands 10,000 requests per second, and then you will be able to hire a whole team of hplus types to solve all your problems

Read the above wall of text. Post is pointless and I have no need to hire teams of hplus's. The point of this forum ( as far as I understood it ) was for would be game developers to help one another grow and develop. I am not asking for direct answers or for people to do the work for me, what I did ask is how people would do it or what ideas they might have when dealing with such a request. Information like that can lead me to the answers I am really looking for and save me wasted time of wading through thousands of hours of bullshit that has no relevance to what I am looking for.

Again, thank you for the help hplus, your most recent post was very helpful.

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.

Bashing every poster you don't agree with is hardly a good way to get more help 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?

Once again - you ask about opinion if something is worth the effort, and when people tell you it's not you get angry?

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.

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 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

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.

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:

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.)

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.

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.

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.

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.

In this case this second key you refer to is an authenticator? If it is, AFAIK, it is only a random number generator where you and the server you want to authenticate with have your seed, hence both know the generated number sequence.
The number generated by the authenticator is not used in the Public Key algorithm.