Taipans Multiplayer Specification

[Bard 0]

.. a sim in the future.

 

I've been scribbling notes for a multiplayer specification whilst commuting to work and am starting to put it down on.. bytes ;)

 

a draft of the first portion "supernodes" is up at http://taipans.dyndns.org/network%20design%20spec.htm

 

this first part is on a logical network structure that should allow for many more players to be involved than we can normally have due to upstream limits of hosts.

 

the intention is to have a complete specification put together in a couple of weeks to give devs of upcoming sims something to think about, and maybe save some headwork.

 

Cheers.

[jeroen79 0]

Neat.

I suppose you could link even more players if you implement several layers of supernodes.

 

Is it strictly necessary to pause the game if a node falls out?

All the attached clients would need to do is contact the central server and request a new node to connect to.

They could even get the ip address of a backup node at the start.

 

The temporarily disconnected clients would be subjected to some lag but it shouldn't take very long unless you are reorganizing everything.

Right?

 

We could also have dedicated supernodes.

[scary_pigeon 0]

at the moment everybody still uses server-client model of one form or another because of the security issues.

 

Basically the client ought not to be trusted at all - the system suggested in the link looks like its a form of peer to peer.

 

Peer to Peer is actually interesting in some ways - the defacto standard of the internet is ever becoming ethernet. Like my broadband connection - the activity light is always flickering even when my computer is off -because it is picking up - and ignoring traffic around my neighbourhood.

 

Basically in a connectionless broadcast network that is ethernet - that continues to form the backbone of the internet as a growing defacto standard as opposed to how it was supposed to be - ATM - then a lot of packets broadcast go to everybody anyway so a udp - peer to peer broadcast to all approach to network games is probably the way to go in the future.

 

So all those security implications with peer to peer would ideally have to be solved. When I was researching this a few years ago it appeared that many ISP's blocked UDP broadcast packets which is a bit of a shame.

 

But for this game - the network approach will be a traditional server-client approach.

[jeroen79 0]

The server could still be the central controller.

Instead of sending 100 packets to 100 clients it sends 10 packets to 10 supernodes, thus reducing the load on the server by 90%.

The supernodes then pass the packets on to 10 clients each.

[scary_pigeon 0]

ah yes - i thought it meant the client was a server-client that sort of autonomously decided weather it was worthy of declaring itself a supernode.

 

but yep - in my daydreams of massive multiplayer net coding - I do indeed envisage an a sort of server farm - perhaps ones overseas with a fast connection to the central one.

[Bard 0]

You wouldn't want to have multiple layers of supernodes for the latency issues - and the cascading effect errors could have.

 

The situation it would work well using layered would be in a LAN, but since you've got enough bandwidth it's pretty pointless.

 

I wouldn't want the supernodes to be automatically generated, just the supernode's user saying "use me as a supernode" and maybe the server host "authorising" the system.

 

Falcon had a variant of this when not only the traffic could be layered, but the actual management of entities was distributed - only problem was that it fell apart. I don't know anyone who tried to layer the connections but I remember that the possibility to do so was discovered at some stage.

 

The second part to this spec should be posted some time this weekend (valentines day and honeydo's permitting) - this part will be purely on the client's multiplayer interface and functionality.

 

I can't see pausing being a particular problem - better than stopping the session and restarting altogether as you'd be forced to do with other sims.

 

The autobalance could just have a great big green button that says "CONTINUE" that the server host could click on easily - the reason for the pause is that some sort of resynchronisation will have to occur for each of the displaced supernode clients - better to know that it's being done than just to have some warping/pausing with no apparent reason.

Edited February 13, 2004 by Bard

[Bard 0]

honeydo's got in the way ;)