hplus0603

Much clearer now, thanks. Leaves me with 1 more question: What happens when there's let's say 10 clients behind a NAT and 2 of them random the same port? Will the router manage? Or do I have to handle such an event in the client app (if so, how to detect it?).

If two clients are behind the same NAT, the router will not allocate the same external port for both clients.

As a server, you should bind to a known port, on a known address, and receive packets using recvfrom().
recvfrom() will tell you the address you should reply to. This will generally be the external IP/port combination of each client.

As a client, you should just create a socket, and call sendto() to the server ip:port.
The first time you do this, the UDP implementation will bind to some random port on the local machine.
That same port will be re-used for eacn successive sendto().
The NAT gateway between the client and the server will map that inner ip:port to some UNIQUE outer ip:port, which is visible to the server.
For all intents and purposes, that outer ip:port is "the address of the client" for the server.

There is one special case: If the server and the client are behind the same NAT gateway, some NAT gateways do not do "hairpin" NAT where they will allow an inside-initiated connection to an inside-exposed server. This is mainly the case when you use NAT punch-through for user-hosted servers.
The solution to that problem is to discover that the client and the server are on the same network -- for example, by the server's public and private IP both being available in discovery, and each client trying the internal IP first. Might want to use some random session ID as part of that protocol, too, to make sure it doesn't get confused with other things running :-)

Nothing is "easy" when it comes to hosting servers, unfortunately.

You can build a server using whatever technology you want. However, when it comes to Flash plug-ins, they will only connect back to the host that served the plug-in itself, to avoid cross-site scripting attacks. This means that you can't have users host the servers, unless you want them to also host the plug-in itself. That's of course possible, but means that each user who wants to host games will also have to set up proper port forwarding through their firewall/router, at a minimum.

You can write the server in Java, Smartfox, Node.js, Erlang or Visual Basic -- there's not really a big difference. Although some of the servers (those specific to Flash) are likely to have more "easy quick start" type documentation, if you need help getting things up and running.

Is it possible that a slow or problematic client will block for too long and stop program flow to the other clients (same with the recieve side of things)?

Yes, absolutely!

I recommend that you remove as many unknown factors as possible. If you aren't already very well versed in threading (and just finding out about EnterCriticalSection() seems like you aren't), I suggest starting with an approach based on select() and send() and recv(). That approach will get you to 63 connected clients on Windows, and 1000-odd connected clients on UNIX, with pretty decent performance, in a single thread.

If you actually want to provide a good threading API as well, then chances are that you need to get a lot more experience before you'll get to the point that you can compete with systems like boost::asio.

and it's an asynchronous while i needs it asynchronous coz it's a server for a gameserver

Actually, the list of the tutorials talks about sync and async TCP and UDP, so you can find what you need right there: http://www.boost.org/doc/libs/1_46_0/doc/html/boost_asio/tutorial.html
All the functions are documented in the reference: http://www.boost.org/doc/libs/1_46_0/doc/html/boost_asio/reference.html
If you know C++, and understand asynchronous/event-driven/callback-based/reactor-style programming (many names for the same thing), boost::asio can serve your C++ networking needs very well.

i got this 3d game project all coding part regarding the quick race have already been done by my friend
i have to implement the local multiplayer support to it by my own....any idea how to do that

First, start with the FAQ for this forum. You can find it at the top.

Second, you should realize that networking is *generally* not something that you just "bolt on" (like, say, some nice particle effects). Instead, successful networked games are designed from the ground up to run the simulation in a way that works well for the latencies involved in networking.

If all you need to support is WiFi for two players, then perhaps you can hack something in, and it might be good enough. However, if you need to support more players, or if you need to support cross-Internet play, then you need to go back and re-architect the simulation, the controls, and even the presentation to support multiplayer racing. (Also: racing games are some of the harder to get right in internet play, the only harder kind I can think of is two-player fighting games)

What I would do if you truly only need support for one local opponent, is to matchmake the players somehow (say, using UDP broadcasts, or use Bonjour if it's available). Then I'd treat each remote player as an AI player on the local system. The trick is that you have to forward extrapolate the remote player by at least one simulation tick -- basically, take the last-received data from the remote player, wind it forward TWO ticks, and make that the "desired target" for the local AI player representing the remote player. There are some more problems, mostly having to do with collisions, where one player detects a collision but the other does not. I would solve these, in the case that you suggest, by each player that detects a collision sending an event to that effect to the other player, and applying the same collision impulse on the other players' machine, even though it will be a tick or two late. And if you detect that a big-crash happens, make sure you synchronize this event, too! This works, as long as you can make sure that nobody cheats by hacking the client. In a local WiFi two-player game iOS, that is usually an OK assumption. For games on the internet, not so much!

Also, WiFi is good because you have a higher data rate. You can send a full rigid body state for each car -- position, orientation, velocity and angular momentum -- for each simulation step. (This is assuming that you're actually doing a physics simulation)

I want to build an online multiplayer board game with players stats, premium members payment etc, like chess.com  or bridgebase.com , in slightly scaled down version.


1. webpage,
2. networking,
3. to write to the database,
4. to handle credit card payments.
5. Finally a good web and database hosting site.

1. Anything will do. Really. If you want tried-and-true that lets you get going quickly, go with PHP and perhaps some PHP framework (although some people say PHP is a framework in itself). You could even write it in J2EE if that's what you know, but I'd recommend against it. If you're adventurous, you might want to look into new-fangles systems like Node.js and Redis and whatnot, but I don't think that's needed in your particular case.
Btw: given the cost structure of Oracle, I would never use that for a web-based business. MySQL is tried-and-true. BigTable (Google) or SimpleDB are highly scalable and redundant service-based offerings, easy to use via HTTP. Key/value stores like Membase, RIAK, CouchDB or Redis are more of a specialty area, and probably not necessary for your particular use case.

2. Networking of WHAT? You can build networking on top of HTTP, as long as your command rate is low and you're OK with paying HTTP request header overhead. You can build a simple TCP-based messaging system in a few hours on top of winsock. You can use a pre-built library like Enet (free) or RakNet (combined free/pay-for) or something else. You have to be more specific in your requirements. Do you want to build matchmaking yourself or get it in the library? How about player chat? Lobbies? NAT punch-through?
Is this an installable application? For what operating systems? Or does it run in a web browser? As a plug-in? Using what technology?

3. PHP can write to the database. As can almost any other application server language. More interesting question: Who decides what to write? How will you avoid player cheating, like attaching to your game with a debugger and making it send packets it wouldn't otherwise send?

4. Morass. Warning! Beware! Users will steal credit cards and use on your site. Users will "borrow" cards from their friends or parents and use on your site. Users will use their own cards, and then change their minds. In each case, they will call their bank, saying "I didn't pay for that," and you will get a charge-back, which costs money, and if you get too many of them, you'll be dropped from the credit card provider. If you want to do this as a business, you need to hire people who know how to deal with this.
That being said, there are two ways to go: managed provider (Google Checkout, PayPal, Amazon Checkout, etc), or merchant bank. Managed providers charge higher fees, make it easier to get going, but ultimately add little value (and may in fact make it harder to pre-screen for fraud). Merchant banks charge lower fees, require integration (typically through some SOAP or XMLRPC callback) and let you do most of the front-end work, such as collecting billing addresses and whatnot.
You can choose various e-commerce packages from various web hosting providers, and my general feeling is that they are all terrible, and you're better off doing your own if that's the way you want to go.
Expect to spend at least 50% of your time on this part of the system, both when building, and when operating the system.

5. You get what you pay for. For "shared hosting," I've always been okay with DreamHost, at around $10/month. I wouldn't run a commercial site on that kind of plan, though. This means you have to pay for specific capacity. There are three options:
- virtual private servers -- many webhosts have these (including DreamHost)
- self-managed servers -- no virtualization; you get the real hardware! interserver.net and serverbeach.com are two of many possible hosts; Interserver has a "starter" option for about $39/month which is an Atom-based, 1 GB RAM host.
- cloud-based servers -- Rackspace and IBM and Microsoft have "offerings," but really, you want to be on the Amazon Cloud. If you don't tie yourself to a single availability zone, you won't be hit by outages like the one they had the other week. Google App Engine might be an option, but they charge by the "user," in a way that is more aimed at enterprise IT than public services AFAICT. Expect to pay several hundred dollars a month in hosting fees just to get started with a properly replicated, scalable, robust cloud solution. Then again, you'd get a properly replicated, scalable, robust solution :-)

If you want more specific answers, I suggest you write up a more specific, precise, question -- or hire someone to consult :-)

Hey, Im still with that simple class for handling networking..If my connections are all TCP, is the behavior of lost connections well defined? for example, if a connection is lost( the client exploded its computer), will I get an error when attempting to send() from the server( WSAECONNRESET or WSAECONNRESET ) or it can just hang without noticing me?

Should I create a method only for testing if the sockets are still connected or I can relly on the failures when sending(if send fails, close the socket)?

If the remote end goes away without sending FIN or RST, then the TCP connection will "hang" until it times out. The time-out time on the sending side varies by implementation, and has been known to be measured in hours for certain server systems.

What are the best/most common/standard ways to handle errors returned by sendto()?

Generally, you want the networking code to be double-buffering with your game code.

The game code will do two things each frame/loop/tick:

1) Look to see whether there's enough incoming data in the in buffer for a full packet, and if so, decode and handle that packet. Repeat.
2) Put a copy of any packet destined to go out in the outgoing queue.

The networking code will then do two things:

1) recv() as much data as it can in a single sweep into the incoming buffer. You may wish to limit the amount of data recv()-ed per frame/loop to something like 4k or 8k. This data will be visible to the game code during the next frame.
2) send() as much data as it can in a single sweep out of the outgoing buffer. The implementation may or may not accept all of the data you try to push at it, but that's OK, because the rest is still in the buffer.

If the incoming or outgoing buffers become too full (say, bigger than 32 k, or some other arbitrary limit), then the other end is mis-behaving, and your best bet is to just disconnect it before it consumes too much memory.

Q1 ) Would it be possible to do such thing even with crappy or minecraft level graphics for web? I will prefer to based on Flash so I'll also appreciate if someone has any idea about using Unity or Molehill or Away3D or? Afaik there is no UDP for Flash (except P2P which is not possible in this game)

Yes, 3D games can be developed in 3D APIs. Something running in a web browser will likely run less well than something running in C++ in full screen, say by a factor if 1/2. (The specifics vary)
For Flash, you'd have to wait for their 3D version to actually ship, and then actually be installed by users. Don't know about driver support.
For WebGL, later versions of Firefox and Chrome will actually allow you to do it straight in a HTML Canvas, but a large amount of installed drivers for users are black listed, because the fact that GL drivers suck for regular users was apparently a complete surprise to the Firefox and Chrome teams.
For Unity3D, driver support is good, and browser support is good; the main obstacle is that about 50% of all users will have to download the plugin.

Q2) Real question is how much player this server could handle at the same time in a room? I will need 50-80 except spectators. There are some service providers like player.io , but I am not sure if it is possible. Tbh, I'd not invest in such game only if 10 people will be able to play together.

Thanks in advance and my apologies if question was really retard.

The capacity of the server has almost nothing to do with how the client is implemented. Well, if you use Flash, and use Flash XML RPC methods for multiplayer, then it would, but you shouldn't do that :-) Unity3D is the best choice here, because it supports native game-style networking. With Flash and WebGL, you currently generally have to resort to trying to tunnel game-style packets inside some protocol that's not really intended for that. Depending on latency requirements (Quake 2 style, or Unreal Tournament 2010 style? very different!) this may or may not matter.

The main problem you'll likely run into is that Flash 3D and WebGL do not have physics engines built-in, so you'll have to use some JavaScript based physics engine, which generally will not perform as well as a native C++ engine. Unity3D integrates a native physics engine -- I believe PhysX -- and thus will perform better on the client.
On the server, you have the option of running the same simulation (uses lots of CPU per player, makes it harder to cheat), do rough correctness estimation of client-provided data (makes it somewhat hard to do gross cheating), or just trust the client (makes cheating easier). On a "typical" server with a "native" physics engine, I'd expect >200 players per server to be quite possible, assuming you have the right bandwidth. Note that clients generally can't handle that many players -- you'd either need some interest management area-of-view, or split the players on more, smaller maps, say 50 each. If you use simple rules-checking, or no rules-checking at all, these numbers go up by a factor of 10, or even possibly 100. (20,000 players connected to one machine, when all they do is forward messages to each other in clumps of 50, is totally doable).

Note that, when provisioning servers, you want to get *real hardware*. The cloud and virtualized options add too much jitter because of the virtualization to be useful for real-time applications like game physics.

Regarding investments: I'd expect > 50% of the effort to be spent on building art and gameplay for the game; 25% to be spent on getting the networking and server infrastructure right; and the final 25% spent on game programming, engine flinging, client integration, and any other programming tasks. These are very rought, and assume that each of the teams know what they're doing. Any team that doesn't know what it's doing will need to double resources, and aim low, and ship early, and then throw away what they did and start over once they know what they're doing :-)

working great until I tested it on some windows machines. The process for my server auto-discovery implementation is as follows: the client begins by sending a broadcast packet with a small message inside (indicating that it is a request for servers). The server, having received the request, sends a unicast message back to the client indicating the name of the server. The problem occurs during the second half of the

You have to bind to the port that the response will be coming on. This may show an automated Windows Firewall dialog box asking whether the program should be allowed, and traffic will not be allowed until the user okays it.
Also, you generally want to install a firewall rule as part of your installer program on Windows (I think the interface is called something like IFwAdmin). Java Applets are not the most optimized host for Windows apps. (In fact, a Silverlight app would probably work better :-)

// Display message from server
char buffer[1000];
memset(buffer,0,999);
int inDataLength=recv(Socket,buffer,1000,0);
std::cout<<buffer;

I agree. That code is pretty terrible! It looks like a typical example of someone thinking "I'm trying to learn this network programming thing, so I'll write a tutorial about how to do it!" and then putting at least four beginner-level mistakes in it.
First, you don't need to clear the buffer before you recv() into it, because recv() will overwrite it and doesn't care what's in it.
Second, you need to make sure you manually zero terminate the string, because recv() may not actually return a zero-terminated string. As it is, a string of 999 or of 1000 bytes will not be zero terminated (because only the first 999 bytes are cleared, so the last byte is non-0, and that last byte may or may not be overwritten by the call to recv()).
Third, it needs to test inDataLength for a return value of less than 1, which generally means some error condition. ("stream closed" on 0, if it's TCP, and "error" on -1)
Fourth, if this is using TCP, which is likely because it's recv() instead of recvfrom(), then that code will totally lose all bytes after an embedded 0, which may be all or part of whatever the next message was that the other end sent.

@hodgman - I think this is exactly what I was looking for! The clientID + local counter generates a unique ID number for every new object.

@hplus0603 - I was under the impression that if clients created new unit IDs via "New unit ID = total unit count + 1", it opened the possibility for multiple units getting the same ID number.  Such as, if two clients both created units during the same lockstep "turn" -- during that turn, wouldn't both clients generate the exact same "total unit count + 1" value?

Maybe I'm misunderstanding how lockstep works?

It sounds like you're misunderstanding how lockstep works, yes. In lockstep execution, UI to give commands is separated from the command queue to execute commands.
On turn N, users will issue commands through the UI. These commands will be queued for turn N+M, where M is the maximum transmission latency.
On turn N+M, all users will have gotten all the commands from other users, and sorted them in the same order, and then executes all those commands.
If, at turn N+M, you haven't gotten a "done with turn N" message from all the peers, then there is a disconnect/lag event, and you have to stall simulation until you resolve it.
Because everybody is executing the same commands in the same order, the simulation will be exactly the same, and thus the IDs will be allocated exactly the same.
If this is not how your simulation works, then it's not a lock-step simulation.

I'm creating a lockstep multiplayer game, and I'm having trouble creating unique IDs for my newly-spawned objects (for example, when a new tank is spawned in an RTS game).  All clients would then use this ID number to refer to the object.

I'm using a peer-to-peer model, so I don't have a central server keeping track of every object. How does one approach generating a series of unique object IDs in a peer-to-peer model? Basically, I'd like to assign a unique ID number to every object I spawn.  At first I kept a running "LastID" counter across the clients that increments every time an object is created, but it seems there should be a better way to do this locally.

If you're using lock-step, then all the peers will create the same unit with the same ID, so there should be no problem. Use whatever method you want (such as a running counter of number of units spawned in game).

TCP will handle this for you. Any connection issues will manifest as high latency, which won't really affect you since you're turn-based.

Not really. TCP can't deal with events like changing the IP address of the host, which I believe will happen when your phone goes out of coverage and comes back into coverage (or gets turned off, or whatever).
Also, your particular game may very well be killed by the phone because it's low priority, when the game is in the background and the user is using the phone for other things (surfing youtube or whatever).
Thus, I suggest you poll the service. If the game play speed is "days" then I suggest you poll maybe once an hour by default, and have a user option to poll manually if needed. The Twitter API, which probably has a lot more immediacy than a game where a turn is a day, is still based around polling.

I suggest that you keep a queue of events that the user needs to see. These can be numbered. When the user polls, you simply check whether there are any events with an id higher than what the user last saw -- which can be provided by the client. If you use Redis to keep state, or if you use a primary key of (userid, eventid), then the query will be fairly efficient. The code on the client is super simple, too:

1) find the highest event id seen since last poll
2) query https://mygame.com/events?last=<last-event-id> using HTTP Basic authorization for username/password (convenient, and safe over HTTPS)
3) for each event returned, deal with it, and save it as the highest seen event id

Could you explain this "for dummies"?

That's what the articule about authentication for game serversdoes.