Not a game but for all intensive purposes the same thing, I have a real-time 3D medical simulation environment (C++, multiplatform Windows/iOS). One thing I'd love to do is join a session with a user so I can see what they're doing, and be able to take over to demonstrate to them.
I don't really want to write server-side applications if they're not needed but other than using 3rd-party server middleware (Smartfox) I haven't done real-time multiplayer stuff and have a few questions:
How hard is it to get a P2P connection between two arbitrary computers anywhere on the web, typically at least one behind a company firewall? Users are quite typically not very technical and while telling their workstation firewall "yes allow access" is OK, getting them to open ports would be a problem... plus every extra step is a barrier to them actually bothering through when I send them a free version and want to demo it.
If it is strictly a 2-player scenario, is P2P better or would you tend to write a server application regardless?
What about a 'hybrid' setup where sessions are P2P but a simple server is used to facilitate things?
What are the main C++ cross-platform libraries these days? It's been 15 years since I was doing this stuff as a hobby :)
Second: P2P requires either port forwarding or a central matchmaking server (and even so, it doesn't always work.) It will be more robust to use a "real" game session server, even if all it does is forward messages between the players.
Cross-platform libraries to do what? For networking, and a number of low-level primitives, there's Boost. boost.asio is great.
Cross platform libraries applicable to C++ networking... when I was a kid doing hobby coding people talked about RakNet but that was a long time back. I was thinking something a step or two above the bare networking stuff, I don't know if boost comes under that category or not, I don't think it was around back then! Has boost made 3rd-party libs redundant? I think a middleware solution (like SmartFox) is perhaps a bit too far but I'm not sure.
Can you elaborate why a real game server resolves problems with port forwarding, etc? Whether the client on your PC is talking to a server or directly to the client on my PC, it has to establish a connection to a remote PC so what are the differences, technically?
Ouch, pricey though. $8k+ per application (http://www.jenkinssoftware.com/pricing.html). I will have to contact them and ask how they word their hobbyist license e.g. if my company has turnover $101k and I develop 5 demo applications to showcase our technology but don't attract any revenue... clearly RakNet has grown up a lot since 2000 :)
So you've got either your custom servers or your $8000 investment in RakNet going. Your game lobby starts up. Computers join. You have a partial mesh of P2P nodes, with either something acting as a repeater to get to the less-connected P2P nodes or you luckily manage to build a complete mesh...
... Then what?
You have a bunch of computers listening and ready to communicate. That part isn't so hard.
Connectivity has been a solved problem for a half century. Network topology is easy. Your specific game or medical simulation, however, is probably at least partilly a novel problem.
What are you planning on communicating?
How do you actually communicate "the game", or medical simulation, whatever information that is? What is your protocol? Who listens to what? What do they do in response? Who coordinates what happens next? What happens when the mesh changes, either when a node drops out or when a connection drops out yet the player is still partly connected? What happens when someone suffers a bad connection, should they vote to drop? Is a machine selected as a local hosting master, and what happens if they are dropped? How does the processing happen, and what (if anything) do they report back to central coordinators?
Some systems and protocols lend themselves nicely to this kind of environment. Distribution is well-studied, and scatter/gather problem solving across a network is commonplace; the acronym I learned two decades ago was PCAM, Partition, Communication, Agglomeration, Mapping, allowing you to study just about any computable problem and spread it across a network of machines.
The work is not in the networking itself, but it building the individual clients and the protocol that they share.
Good points although the "gamestate" is probably not going to be very complex compared to a game.
When you talk about P2P I think you're talking about a more complete P"P network along the lines of Skype? Dynamically changing how nodes connect? I'm talking about an old fashioned P2P session where each member talks to (all) the others... in reality there would only be 2 players which is something of a special case. If it wasn't 2 players I'd probably go straight to a server-client model, because it is I find myself in a quandary if putting a server in the middle is the right thing to do or not.
When all clients can directly address any other client, that is called a fully connected mesh. It is perhaps the easiest method of network programming. It is what many programming environments will simulate given the chance, hiding any internal routing that must take place.
Having a server in the middle, where everybody communicates with that central hub and the central hub relays the information is called a star. It is also fairly easy to work on, since as a client you always know who is on the opposite end, and you can route your messages indirectly through the hub node to anybody.
As far as network programming is concerned, those are the easy off-the-shelf parts. No drama or difficulty, they are assumed to be present and debugged.
Network topology has been solved for about 50 years. Go to your favorite used bookstore, buy a network programming college text from the 1970s or 1980s and they'll explain all the details of all the topologies in usually far better terms than a modern book where everything is hidden by the magic of the Internet.
But those are not the interesting bits. Those are not really the things you need to consider, other than the occasional connectivity hiccup and dropped connection.
Once you have your connectivity, what do you plan on transmitting? How do you partition your problems, and why? How do you establish what to communicate, and why? How do you decide what gets placed where, and what gets mapped to what machine, and why? That is where things start to get interesting.
Source code that shows TCP hole punching in C or C++ is harder to find (I found C# examples, Java examples, but I failed to find any C or C++ example).
But then, the first issue is not connection : it's identification. What is the IP/port address of an unknown distant machine? If you're playing on the local network you can setup some broadcast-based discovery protocol (a la upnp). But you can't use that on the internet and thus you need to setup something to help your users to find another player (using what is called a rendezvous protocol : http://en.wikipedia.org/wiki/Rendezvous_protocol).
