Light weight server. Comments?

I''ve been exploring peer to peer options for gaming for quite some time now, and I''ve found that the n-node problems involved are generally either insoluble or result in a system that has a pathetically high latency. So I''ve come up with a different solution to the same problem, and I''d like some comments on it. I''m implementing a prototype proof of concept at the moment; any thoughts before I finalise the prototype architecture are what I''m really looking for. The basic system: The server is light-weight and performs protocol validation and packet forwarding only. The clients connect to the server in client-server mode, but each client runs an entire game state. Any update from any client is sent to the server which performs source validation, and if it is valid, passes the request on to the connected clients. It''s simple, it''s clean. It''s generally extensible by expanding the count of trusted servers and having servers talk to each other through a minimum spanning tree of servers. Problems: * If all clients start at the same time (t = 0) it''s all good, for example for an RTS. No problem. For a game where there is persistent game state even when no clients are connected (eg. online rpg) this doesn''t work. I''m contemplating some kind of data-resource clients which are special (trusted) authoritive clients that can be used to update the game state of late joiners, or something. thoughts? * Server clustering. This is the standard stupid thing about c/s architecture. When too many clients or clients use too much bandwidth the server chokes and lags. Multiple servers reduces the problem, but its (as always) an issue. Especially a problem if clients all cluster around a fast server. * Protocol validation is actually a lot harder than it sounds. The point of the servers is that like a standard ip forwarding machine it has fast core functionality of forwarding packets. The most processing it does to check validation, the slower it is, but the more secure. At the very least it MUST validate any request which says it comes from a specific client actually comes from that client. Anyway. Any general thoughts on this? Know of any (open-sourced preferably, or at least documented) implementations of a similar system? Cheers!