Client - non dedicated server architecture

Civilization 4 & 5 have a pretty robust master-server-less multiplayer, so it is definitely feasible - you can even have players join and leave during the middle of a game with no problems. You have to do more planning to handle data disparity, since none of the data is "canonical" and you can't just throw the conflicting data away (or you have to decide on which client's data is the master representation). If your simulation isn't deterministic, you'll need to figure out a way to reconcile floating point errors between different clients.

You need to be clear on your terminology:

Peer-to-Peer is a network architecture. You are discussing a client-server architecture, so there is no "peer-to-peer" here.

Dedicated server versus server-with-local-player is an implementation issue.

Consumer-hosted versus Publisher-or-Developer-hosted is a business model.

If you have a lobby server or master-server list in the clear, it can do NAT tunneling for you, so there is no need for someone to have a firewall setup correctly.

Yes, it's totally feasible to let players host servers.
The main problem you'll need to solve is "how do players who want to join, find a server to join?"
One option is a central matchmaker server, but you could just tell people to do port forwarding, and post their server IP/port on an internet forum, and that might work just fine for your game.

Civilization 4 & 5 have a pretty robust master-server-less multiplayer, so it is definitely feasible - you can even have players join and leave during the middle of a game with no problems.

This sounds good :)

The main problem you'll need to solve is "how do players who want to join, find a server to join?"
One option is a central matchmaker server, but you could just tell people to do port forwarding, and post their server IP/port on an internet forum, and that might work just fine for your game.

I would prefer a central matchmaker/lobby server.

If you have a lobby server or master-server list in the clear, it can do NAT tunneling for you, so there is no need for someone to have a firewall setup correctly.

You ever have tried to establish a 8 player RTS session with random people, even when using a master-server ? Ever have tried to establish a tcp NAT punch through ?

If you have a lobby server or master-server list in the clear, it can do NAT tunneling for you, so there is no need for someone to have a firewall setup correctly.

You ever have tried to establish a 8 player RTS session with random people, even when using a master-server ? Ever have tried to establish a tcp NAT punch through ?

As far as I know, you cannot do a TCP NAT punch through; it is the prevalence of NAT in the consumer space that was the real reason to drop use of TCP for consumer hosted games.

And RTS games are the classic example of games that are run on a Peer-to-Peer architecture rather than client/server model, in part because of the ability for a player to be defeated early in a long running game.

What exactly are you trying to do?

you cannot do a TCP NAT punch through

Why not? TCP simultaneous open is a totally supported part of the protocol. Windows 98 didn't do that so well, but any modern network stack supports it. A large fraction of home routers also supported it last I saw numbers, although not as quite large as UDP punch through. Note that my numbers are by now pretty old (2009 time frame?) so the installed landscape may have changed some, but certainly not super drastically.

Anyway, you can easily use a reliable layer on top of UDP, such as you get with ENet for example, if you don't want to use TCP. It shouldn't make very much difference to most of your application.

UDP NAT punch through depends on the ability to talk to the matchmaker and the other machines over the same UDP port. I don't see how you'd make that work with TCP, although I'd be fascinated to hear how.

fascinated to hear how.

Wikipedia to the rescue

What exactly are you trying to do?

I want a small multiplayer game (~2-4 players), which avoids the hassle of P2P (massive NAT issues), benefits from a classic client-server architecture (not only the network archtecture, but the classic asyncroniously game flow too, e.g. dynamic joining of new players, no out-sync due to a deterministic lock-step simulation etc.) , without the need to provide dedicated servers ($$$) to play.

Note that player-hosted servers still count topologically as "p2p" and has NAT issues.

Note that player-hosted servers still count topologically as "p2p" and has NAT issues.

I disagree, actually.

For me, there are two hallmarks of a peer-to-peer architecture. The first is that every machine has a connection to every other machine, and the second is that each machine is equally authoritative as to overall game state as every other machine.

The latter is a matter of game architecture, but the former is definitely network topology.

The client-server network topology also makes some things dramatically easier. Consider the simplest possible case where the topology would differ. We have three players, Bob, Ted, and Alice.

It is quite possible for it to be the case that Bob has a great connection to Ted, and Alice has a great connection to Ted, but latency or packet loss issues make Bob's connection to Alice dubious. This case happens often enough that, if memory serves me correctly, at least one of the Age of ____ games would do its own routing when it detected that circumstance (moving the direct connection between Bob and Alice into a connection routed via Ted) .

In a true client-server network topology, it wouldn't matter, as all network traffic is routed via the server anyway, with no direct connection between Bob and Alice, making it much easier to find a game in which all players will have a good network connection.

It does of course still have NAT issues, but that hasn't been an unsolved problem for over a decade.