hplus0603Member Since 03 Jun 2003
Offline Last Active Yesterday, 10:49 PM
- Group Moderators
- Active Posts 11,101
- Profile Views 21,578
- Submitted Links 0
- Member Title Moderator - Multiplayer and Network Programming
- Age Age Unknown
- Birthday Birthday Unknown
Redwood City, CA
Posted by hplus0603 on 10 January 2015 - 11:27 AM
The dropped packet indicators always start on the inside of Comcast's network, but outside my local link, so it's likely an internal capacity problem on their network.
Meanwhile, I've seen experiments run with 10 million UDP packets sent from a data center on the west coast, to a data center on the east coast, using regular transit (not leased lines) and not a single packet dropped!
In addition to Comcast customers, WiFi and mobile networks will cause more packet drop than wired.
Posted by hplus0603 on 10 January 2015 - 11:14 AM
If you were gonna make a multiplayer game with collidable cars in Unity
Here's where I would start:
Is this mobile or desktop? On desktop, run physics at a much higher rate (120 Hz is good for cars!)
Then up the transmit rate to something like 40 Hz (again, assuming not mobile.) Send position/velocity/orientation/spin in each checkpoint -- hope you don't have too many cars!
Then locally simulate collisions on each client, but also send collision events as detected on the server, and play the same sound effects/camera shake when getting a server-side message.
On mobile? Try the last thing, but expect that it won't be very good. Perhaps try another kind of game :-/
Posted by hplus0603 on 09 January 2015 - 05:33 PM
I wonder if it would be feasable to simulate on the clients and server and send occasional absolute positions and correct the cars over time.
Yes, this can work. If the cars are "scenery" and seldom actually collide, and/or don't matter much for the gameplay, then users might not care about the occasional inconsistencies. If the cars are an essential part of gameplay, users may feel that it's "too glitchy," though.
Posted by hplus0603 on 08 January 2015 - 11:06 PM
After that, you really need to define how much latency is OK for you, and how your game design wants to deal with it. For example, it will VERY LIKELY be the case that, on machine A, player A will think that thon is front/left of player B. Meanwhile, on machine B, player B will think that player A is behind/left. If player A now does a lane shift to the right, will the outcome be:
1. Player A is ahead of B in the same lane (looks correct for A)
2. Player A is behind of B in the same lane (looks correct for B)
3. Player A actually sideswipes player B (what likely happens on the server.)
You have to figure out how your physics and networking interact in this case, and then design your game to make sense in this situation. Then you have to code that up -- and exactly what that looks like, depends on your game design.
Posted by hplus0603 on 08 January 2015 - 11:01 PM
i think bway to face this kind of hack is encrypting.
That doesn't really work, because the data is available in the memory of the client, and it's easy to DLL inject or debug attach to a process, and change the data right in the process memory. Instead, you have to put all the important game rules on the server, and send player moves/commands from the client. Don't send "unit A moves to position X, Y" -- instead, send "unit A moves range R in direction D." Then verify that that unit has that much movement range, and that direction D is in fact clear to move on the server, and move the unit. Send back "Unit A is now at position X, Y." Do the same method for all other important actions that can change important game state.
next one is sql injection that i dont know really how does it work but i think its some kind of hack that they can change in your database.
Here is a piece of server code (in PHP) which can be SQL injected:
$result = db_query("SELECT * FROM customers WHERE customer_id=$_POST[customer]"); // VERY BADHere is the same code without the possibility of SQL injection:
$result = db_query("SELECT * FROM customers WHERE customer_id=:cid", ['cid'=>$_POST['customer']]); // BETTERThe difference is that the user could change the output of db_query in case 1 by sending a "customer" named something like "0 OR 1 = 1" which would return all the customers. For another illustration: http://xkcd.com/327/
or next one is ddos hack that send a lot of traffic to your server that it cant handle it.
The three defenses against DDoS are:
1. Don't piss of anyone or seem like a target (doesn't work in the long term.)
2. Don't be so dependent on uptime that a DDoS is a real problem (communicate to your players on Facebook, and hope they go away after a while.)
3. Contract with a DDoS prevention company like CloudFront or Neustar or Verisign or whatever. When the DDoS hits, work with them and follow their instructions. (Ideally, try the procedure once before you're attacked, so you know it works :-)
a much more exprienced friend in networking said if you just do all security rules there will be just little group of people can hack you game
Sadly, that small group, if it doesn't like you (or has economic incentive) will create a hack script that anyone can download (or buy) and hack your game.
Put rules on the server. Write safe server-side code. Subscribe to vulnerability mailing lists (like CERT.) Patch all your servers (and client libraries you use) as soon as there is a vulnerability (not next week, not next day, as soon as!) Write good server logs; keep the logs for a reasonable amount of time. Keep netflow logs for attack analysis. Go through the logs at some regular interval, and look for new patterns you haven't seen before. Set up good server monitoring and warning systems. Keep good connections with your community, and listen to them when they complain about cheaters and hacks and broken behavior -- sometimes they're right, othertimes they aren't. Keep good backups. Run databases with time delayed replication slaves. Buy external penetration testing services. Configure a firewall well to only allow in (and out) the data you *know* that your service needs (use white-listing, not black-listing.)
The set of good operational practices goes on and on (and on.) If this is ACTUALLY the biggest problem for you, hiring an experienced operations manager is likely a smart move for you. Chances are, your CURRENT biggest problem is likely that "we don't yet have a game that's fun enough that people would care." After you solve that, your biggest problem will be "nobody knows about us, and buying advertising is so expensive, and all the app stores have a million apps that are ranked higher than us, so nobody knows that they want to play our game." After that, your biggest problem might be "oh, our payment and customer service system is all wrong and doesn't actually make it easy for users to give us money (and take care of the cases where that fails for some reason.)" After THAT you probably actually need to start thinking about managing all your infrastructure for real. Unless you are really, really, REALLY sure that you'll actually get all the way there, spending too much work on the operational aspects now is probably wasted.
Meanwhile, making sure that all commands are executed and validated on the server, is something you should do up front -- it's the same cost to write it server-side or client-side, but doing it server-side is "right" and doing it client-side is very hard to "fix" later.
Posted by hplus0603 on 07 January 2015 - 06:37 PM
When I wrote a version of this, I put both "currently available games" and "players seeking games" in RAM only. This was more for a FPS-like experience, where games may be shorter, and player are at least semi-often looking for new matches.
A server that is currently accepting users would send an update with current game state (name/mode/current-players/open-slots/whatever) every 5 seconds or so. When the lobby server hasn't heard from a game hosting server for 12 seconds, it would drop that game from its list of available-to-match games.
Meanwhile, a player looking for games would send match parameters, and be sent back a list of games, typically once every 5 seconds as well. If you expect for there to be 100s of matched games in the response, you'll want to manage this with some kind of consistent sorting and pagination.
The only persistent data I'd store in a DB for a game matchmaker would be the user name and password hashes, to verify the user accounts (and perhaps something like a game purchase serial number or whatever.)
Posted by hplus0603 on 07 January 2015 - 06:20 PM
Is it 2D/2.5D/3D?
How much is the focus on skill/die-roll versus action/fps gameplay elements?
How much simulated physics do you need for players? For environment?
How many players do you need to support in a single "area" (whatever that means in your game)?
What happens when more players want to go to the same area than are supported?
What level of lag are you prepared to accept for the player? For group members? For players that are just around? For NPCs? For the NPCs the player is currently fighting?
Is there PvP?
Is there player construction, or other environment modifications?
Will you need a single global world where anyone can meet anyone, or can players choose world instances ("servers" in WoW, EQ, etc)?
How much revenue do you intend to make per player per month? (This dictates what kind of resources you can put into it.)
If you are a small indie group with one or two programmers and three or four artists, you probably want to start somewhere simple, like with the "PyMMO" example, and grow from there as needed: http://www.enchantedage.com/pymmo
Posted by hplus0603 on 06 January 2015 - 11:23 AM
I have never used a database for such high volume data before,
If I were to build it, I would store data that is going to be stale within an hour in RAM, and data that needs to be more persistent than that in a database.
I would also design my protocols to avoid changing persistent data frequently :-) Or, to put another way, any data that changes frequently, should be in RAM, and/or supplied on demand by the client.
Posted by hplus0603 on 05 January 2015 - 10:38 AM
need to find out how many packets per second the average user can process
The number of packets per second is a reasonably meaningless value for most situations (perhaps except for certain mobile situations.)
The reason is that any client computer and client link is likely to be able to process many thousands of empty packets per second.
The real questions are:
- what's in those packets?
- how much is in those packets?
- what are the characteristics of the link between the sender and the receiver?
You have control of #1 and #2, but unfortunately not #3, which means that you have to assume some minimum, and when a client can't fulfill the minimum, detect it and disconnect (giving a clear error message about what the problem is.)
Posted by hplus0603 on 03 January 2015 - 02:29 PM
these will cost you users
If you have a slow influx of users that you can test with (say, by paying $50/month for Google ads or whatever,) then that may be acceptable.
Once you find that some users actually like the game, you figure out how to reach more of those kinds of users, and turn up the efforts.
It's very hard to predict what will be important, and how close you are to "good enough," without actually measuring on real users.
Posted by hplus0603 on 31 December 2014 - 12:58 PM
HTTPS is just HTTP with encryption.
Agreed! Thus, it solves the "encryption" part.
You still end up with like 100-300 bytes of headers in ASCII text that mostly serve no purpose.
I can't think of a single header that's not used by our web stack. Except the Accept: header sent by Internet Explorer when you have Microsoft Office installed -- that's insanely obese.
With HTTP2, you will likely be able to not repeat headers that haven't changed.
You can send binary data in HTTP content but you have to either base64 encode it or use MIME.
If you say something like that in a public forum as if it were fact, it's usually a good idea to verify with the specification first. That makes you look better when you catch yourself from saying falsehoods.
How do you think Flash movies, or JPG images, or application/octet-stream data, is served by a HTTP server?
Posted by hplus0603 on 29 December 2014 - 09:46 PM
Seriously we are long overdue for a binary http-like protocol with encryption and compression built in. Nobody actually uses a terminal to access web servers anymore.
HTTPS fulfills all of that.
HTTPS is encrypted.
HTTPS supports gzip (and other) encodings.
HTTPS supports binary payloads (if you want.)
And, with HTTP2, we may start getting the ability to support multiple separate streams on top of the same connection (for out-of-order, prioritized, and overlapped requests.) SPDY showed the way, and once HTTP2 is finalized, browsers and servers will swap out SPDY to HTTP2.
Posted by hplus0603 on 27 December 2014 - 11:58 AM
Anyone who has tried to do this, realizes that it's actually hard, because each layer in the stack gets in your way.
At work, we've built out all the different library support and back-end infrastructure needed to make really responsive web services, working around various caching and scalability problems.
What the article doesn't say is that we also use the underlying message queue for non-HTTP data, for various games and experiences. But the article was already long enough :-)
Posted by hplus0603 on 19 December 2014 - 04:14 PM
Note: I wouldn't put this on a public host for now, there are probably bugs!
Also, the last commit was 2 years ago, so I don't think it's actively maintained.
That being said, if you clone it and build it and install it for your Apache host, you can likely use Dart in Apache:
If you go the other how to access PHP code from dart client, how to implement it?
Easiest is to decide on an intermediate representation, such as XML or JSON.
Then write POST handlers in PHP, and POST to your Apache/PHP server from your Dart client.