So if I run a host, I can cheat by poking at the memory of the process.

Here's the thing: The train of thought you go down, is a train of thought that many, many, network programmers have gone down for the last 30 years.
It may feel as if it's new and promising to you, because there is no large scale success to look at.
Unfortunately, the reason for that is not that it's a green field ripe for the taking; the reason is that the practicalities all slope heavily towards a hosted-games star-topology approach.

Also, your "one day" followed by "one week" estimate shows that you have very little actual experience with distributed systems development.
The good news is that, the best way of getting such experience, is to combine talking to those who have it, with trying your own things, and analyzing how they actually work once you have them up and running, so you're on the right path!

Yes, that is correct. The same problem occurs in a star-topology as well. The architecture itself is really just a small modification of a star topology; the only difference is that the role of broadcasting is shared by a group of people (called secondary hosts). So all the problems that come with a star-topology apply to this as well.

I am aware of that. But based off of what I've profiled in my own game, it seems that this architecture might work better for the game I'm developing. You never know until you try right?

As a small progress update, I've nearly completed coding the entire host program (based off of one day's of work). I just need to code the client and then do some testing. I may be new to creating multiplayer games, but it doesn't mean I'm a complete amateur when it comes to networking :P

that's not a problem since everyone's simulation is based on the host

So if I run a host, I can cheat by poking at the memory of the process.

This is exactly the issue. Consider the following: A hacker sets up a host where he modifies the memory, and also clients that are set up to confirm the host's actions. The host and the client both verify that the host's information is valid, and communicate that to other hosts.

It's not a secure structure unless you have a dedicated audit machine above each host. But that adds overhead and latency in most cases.

Also could you elaborate on what factors prevented you from scaling up the number of players?

Everything gets more complex. The issue I found was that players would eventually have too much load (processing or network), and have to resolve expensive things like collisions/bounds checking.

In order to help resolve it I essentially had each host act like a zone in a typical MMO, but this added an immense ammount of host migration work. With a system where each host only handles players around him, and communicates state changes to the nearest few hosts at a smaller frequency it was able to handle a good ammount of players.

But nowhere near MMO levels.

I figure'd the only way to reasonably scale it up to the levels you're talking about would be that you need to host dedicated application servers to extrude as much non-time critical code as possible, as well as some dedicated hosts to handle high volume areas. Basicallly what you're looking at is recreating something simimlar to Eve online's application sharding techniques leveraging P2P as well.

Not so say that you shouldn't try, though. I learned a ton about P2P networking while working on my project. I also learned it's just not for me, and haven't touched it since :P Especially with machines being so cheap now, you can easilly run servers on commodity hardware.

If you're actually aiming to do anything other than learning though, I'm working with a fantastic bare-bones library called "darkrift", and am able to get way more players on commodity hardware pretty trivially. A version 2's coming out soon based on this networking stack

https://github.com/DarkRiftNetworking/Hazel-Networking

If you've got experience with optimizing C#/.net GC I'd strongly recommend going this route instead. $150~ for an unlimited license/no monthly fee (or just building your own solution ontop of Hazel) vs working for probably over a year getting everything sorted out, if it's even possible entirely P2P (Which what I've seen indicates it's really not feasible)

The issue of a (primary) host cheating is not that big of an issue IMO. I personally feel that assigning one user as the central authority with the roles of "anti-cheat" and keeping everyone in sync way better than other methods such as a synchronous lockstep mechanism; which is also not 100% foolproof (not to mention the extra overhead).

So based off of what you said, it seems that the problem you were having was more of a computational issue than the actual networking architecture itself? I understand where you're coming from, but the thing with my game is that the bottleneck is NOT computation power; it's bandwidth (even for a large number of players). And this is the only reason why I'm opting for this architecture. If computation was an issue, I would definitely be opting for a dedicated server without question.

I actually already have some pre-written code from previous projects, but thanks for referring me to it :)

The architecture itself is really just a small modification of a star topology

Based on my experience with distributed systems and networking, that sounds a lot like "just a little bit pregnant" to me.

The architecture itself is really just a small modification of a star topology

Based on my experience with distributed systems and networking, that sounds a lot like "just a little bit pregnant" to me.

In simpler terms: It either is, or it is not.

EVERYONE talks with the hub, and only with the hub, then that is a star.

If connections are talking to each other, that is not a star. It is more likely a partial mesh, which is not a star. Even if most communications happen to go through the hub, it is still not a star.

If you modify a star topology and make it something other than a star topology, it stops being a star topology. Continuing to call a non-star topology a star is the wrong name. Hence the analogy to "slightly pregnant". You either ARE or your ARE NOT. There are no modifications that change that fact. You either are a star topology or you are not.

First of all, I never called it a star-topology. I called it a modification of a star-topology.

Secondly, I was saying that this architecture has the exact same advantages/disadvantages as a star-topology. I am quite aware that this is not a star-topology...

this architecture has the exact same advantages/disadvantages as a star-topology

Yes you did. And what we're trying to indicate is that, no, actually, it doesn't.

Anyway, you'll be done in another three days (7 days from June 17,) so we'll see how it works then. Looking forward to it!