Jump to content

  • Log In with Google      Sign In   
  • Create Account


hplus0603

Member Since 03 Jun 2003
Offline Last Active Yesterday, 07:25 PM

#4982548 salt and hash in plain C or C++

Posted by hplus0603 on 21 September 2012 - 07:42 PM

Crypto++ is a high quality, free license cryptographic library for C++.
The command they use to generate a salt is basically just a high quality random number generator (which is included in Crypto++ if your OS supports something like the crypto random number service or /dev/random.)
The command they use for hashing the key just shows that they use the hex encoding of the sha1 hash of the password, which is a medium-strength hash function (well supported in Crypto++.)



#4981505 Where Is The Line Drawn For Too Many Clients?

Posted by hplus0603 on 18 September 2012 - 07:55 PM

what kind of features are you thinking of that rule out a large player count?


Dwarf Fortress level AI for the NPCs?
Radars that track the position of all other players in real time?
Game design that creates very dense areas where all players congregate?
Any other feature that requires N-squared examination of all player pairs?




#4980928 Where Is The Line Drawn For Too Many Clients?

Posted by hplus0603 on 17 September 2012 - 10:25 AM

1,800 players on one server! I don't know how on Earth they achieved that, it sounds too good to be true!


Ten years ago, Planetside had 500 players per server in an FPS. Planetside 2 is coming out soon, I hear.
Five years ago, Sony/Zipper had MAG, with 256 players in a game (on a console.)
If your goal is massive player counts, you simply design the gameplay, simulation, and networking to optimize for that goal. This means there are certain kinds of things you can't do in your game, because it would break the player count target.


#4980671 How Much Bandwidth Should I Plan For?

Posted by hplus0603 on 16 September 2012 - 11:54 AM

Typically, the way that characters move is defined by some simple input, such as "which animation state is the character in" and "how far into the animation is the character." Or even just "what was the previous state of the character, and what was the user input," which lets you simulate everything based on initial game state and user input (the "lock-step" method.)



#4980669 How does networking exacly work?

Posted by hplus0603 on 16 September 2012 - 11:51 AM

No offence but to stay away from people defining you as an idiot it is spelled "exactly". Probably an typo but there are some people who don't think before defining people.


No offense meant, but if you're going to call out people on writing, you probably should spell "offense"(*) and "a typo" correctly, and you probably should also use proper grammar and word choice. "No offense" should write out the implied "meant," "stay away from" should be something like "avoid" or "preclude," and "defining" should be something like "judging."

(*) There are parts of the world where "offence" is an accepted spelling, too, but that's not where Gamedev.net servers are :-)



#4980406 Weapon firing prediction timing issue on Client / Server

Posted by hplus0603 on 15 September 2012 - 09:53 AM

it doesn't know the exact time duration the client held down fire


Simulation should use a fixed time step. For example, 30 steps per second, or 60 steps per second.
Weapon fire only starts and stops on time steps.
Input data should be time stamped with the time step it applies to.



#4979953 Where Is The Line Drawn For Too Many Clients?

Posted by hplus0603 on 14 September 2012 - 12:00 AM

I believe that some large-scale FPS-es with physics, such as Battlefield 3 or APB, run up to 128 players per server.
Also, even EverQuest could have 150 players, and another 100 NPCs, on the same physical server -- this was in 1998!

40 players and 20 NPCs on a single server is not a problem just by itself. It mainly depends on how advanced you want the physics to be, and how advanced you want the NPC AI to be.

On another note, really large games typically split all users across a large number of physics servers (or server processes) and move players between these processes as they move through the world.



#4979567 Server-side inventory system, what to send over the network?

Posted by hplus0603 on 12 September 2012 - 09:55 PM

I would store each item in inventory, together with the position of the top/left coordinate of the item. This only needs 10 bits per item (5 bits for X, 5 bits for Y.) The size of the item should already be known by the client based on the item type.
I would send the full inventory on connect, and only send delta updates when the inventory changes, to minimize traffic.


#4978400 Dealing with high packet loss or long pauses in transmissions in custom UDP p...

Posted by hplus0603 on 09 September 2012 - 04:03 PM

TCP always waits for a return packet that contains an ACK, even if it may contain no data. In UDP, this would be the same: waiting for a return packet with no data. If you don't see that return packet in a while (say, 2x RTT time) then re-transmit. If you still don't see the return packet, back off on the waiting time, and re-transmit; repeat until you give up.

Another option is to keep the packet rate flowing -- say you want to always send at least 1 packet a second, even if there are no messages to send. For games, this is good, because it allows you to quickly detect dropped players, and it will keep any NAT translation table alive. Some broken NAT gateways may time out UDP connections as quickly as a dozen or so seconds if there's no reply.

Finally, you want to separate "messages" (the units of information you communicate) from "packets" (the UDP datagrams you send over the network.) Typically, it's more efficient to acknowledge and sequence number datagrams, and then complete/re-transmit messages based on what you know about what you put into each datagram.



#4976659 Suggestions for 3rd party server for MMO game

Posted by hplus0603 on 04 September 2012 - 08:28 PM

You could use an existing open source server framework, like Node.js with something like Express or socket.io or just raw sockets, if you want JavaScript, or Twisted or Django if you want Python. It's likely that most of your server-side logic will be custom anyway, so if you decide to pay a lot of money for off-the-shelf servers, make sure the functionality you get for the money is actually worth it to you.



#4976657 a few questions about server design

Posted by hplus0603 on 04 September 2012 - 08:24 PM

A Raspberry Pi is $35 and can probably be a lobby server for a thousand players. The hardware cist is not necessarily the problem.

The question is more where the machine is located. If you're thinking of running the machine on your home internet connection, there are usually lots of problems with that set-up.

$100/month lets you rent a basic online self-managed dedicated server that would be sufficient for all matchmaking needs for any typical indie game. In fact, it might be able to run the forums for your game, too :-) The rock bottom dedicated servers start at about $50/month. Cheaper can be had through "virtual private servers" which are fractions of a server, starting as low as $20/month. Make sure you get enough bandwidth for your needs, though -- if you host your own downloads, it may be expensive otherwise. A VPS is fine for a matchmaker and forums machine, but probably not for actual game server processes, because of the scheduling jitter of virtualization.


#4976509 a few questions about server design

Posted by hplus0603 on 04 September 2012 - 12:12 PM

When you're talking to a machine across the network, you have no idea what the code is that's running on the other end. It may be your server. It may be a Python script. It may be an alien that's really good at typing hex code into a telnet window :-)

Thus, the question of "what /could/ a cheater do if I let users host games" is "anything that's possible using your network protocol."

If the network protocol downloads maps from the hosting server, for example, then a malicious hoster could download whatever files he want. A very very large file that takes up all disk space? Files containing all kinds of contraband, terrorist threads, and child porn to make the player vulnerable to law enforcement search? Carefully crafted images that root the machine if opened with a vulnerable image decoder? That kind of thing. You can address this by, for example, setting an upper limit on the size of maps, and enforcing this on the downloaded side, and also enforcing that all assets are "baked into" the map file. You probably also want to ensure that the map file actually conforms to the map file format (header bytes, internal structure) by carefully validating it with code that won't thrash the stack or allocate too much memory if some internal data field is wrong.

If the network protocol allows the affecting of game entities during play (which it most likely does) then the attacker can make whatever entities do whatever he wants, within the limit of what entities can do in your game.

The physical implementation of an attack may be as simple as running a second program on the same machine that runs the server, which injects itself into the server address space and mutates data. Or it may be as complex as a network gateway that intercepts the data packets and re-writes them outside the server machine, totally undetectable to the server process. Or it may not be using your server code at all, instead emulating it using some other program.

Don't get me wrong, though: It's important that you write your networking code to be robust. It should never trust a size field that it hasn't verified is "sane;" it should never trust a piece of data that doesn't have the right header bytes; it should be prepared to deal with reads/writes being "short." Once you do that, the impact of a sophisticated cheater is basically validation: it's a great problem to have, because it means that people care enough about your game to spend the time to do that! Once you have that problem, you can probably figure out a way to make enough money on the game to move the server onto machines you can trust.


#4976459 a few questions about server design

Posted by hplus0603 on 04 September 2012 - 10:11 AM

if one player is being a server, isn't he allowed to easily hack?


Yes.
Many, many games have been quite successful with this model, though. Until just a few years ago, that was the only way that network-hosted games were written.
You still need a server for matching up the hosters with the players, but that's an easier thing to operate.

If you think your game will be popular, and there will be incentive to cheat, then you may need to change to run the servers on your own. The good news, though, is that, because players go to your matchmaking service to find servers, you can make that change later, without breaking anything that already exists.

So, I would recommend this sequence of implementation:
1) Build the game, with manual hosting, and the player having to enter a target address for the game server.
2) Make the game super fun!
3) Build a matchmaker, where hosted games register, and client players can find and join games.
4) Make this matchmaker, and the NAT punch-through, robust!
5) Now if the game is fun and robust, you may start seeing cheaters as a problem. Move servers into your own hosting, and advertise them in the matchmaking as "secure" or "premium" or whatever.

If you complete 1) and 2), you're better off than 99% of all other game projects on the planet :-)


#4976129 a few questions about server design

Posted by hplus0603 on 03 September 2012 - 11:52 AM

All the variants you're talking about have been impemented, and work.

The problem with having players hosting matches is that you have to implement NAT punch-through, and only allow players with working punch-through (or port forwarding) to host matches. The benefit is that you don't need to run the game servers yourself.

The benefit of having lobby and game all in one is that the hand-off and management of "who's online" is simple. The draw-back is that there is an upper limit to the number of games you can run at one time, because the server machine may run out of capacity.

The "best practice" for large-scale systems is to run multiple lobbying processes, and also run multiple game processes (perhaps one game per process, if processes are cheap.) When a player logs in, you'd try to assign him/her to a lobby server where other players on the friend list already are. Or you'd assign be geographic location, or something. The point being that you want players to be on lobby servers where they will find friends to play with, and you also want to scale the number of players beyond what a single server can do for lobbying. Xbox Live actually dynamically splits the lobbying -- for most games, it'll be on a single process, but when enough players are online (for the really big games,) it will split; I believe it will split geographically.



#4975565 a few questions about server design

Posted by hplus0603 on 01 September 2012 - 04:12 PM

Games on top of UDP usually classify messages into "reliable" and "unreliable." "Reliable" messages, when sent, are put into a queue of some sort, and only removed from that queue when the remote end acknowledges the packet that they were put into. If an acknowledge doesn't come in quickly enough, the messages are re-transmitted, until acknowledge is received. This also needs some form of de-duplication on the receiving end (typically implemented using a serial number for reliable messages.)





PARTNERS