After discussing a flawed design in this thread I’ve been looking over the internals of @pspeed’s excellent SimEthereal library, which suits my needs well (and I had wanted to use anyway). However, I’ve hit a snag while attempting to integrate it into my own codebase. My system spatially divides a large game world into separate zones and hosts them across multiple servers. Each running server instance provides a core set of services (networking, threadpool, database access, etc., etc. etc.) to all of the zones running on it. Zone assignments may dynamically change, so it’s important that ip addresses and port numbers are not directly tied to any zone’s simulation. Players connect to a server and are then placed into the right zone, but all network traffic passes through a common instance of the SpiderMonkey server. Zones may, but do not necessarily, physically border each other. A server running a handful of zones may not be running any two that are spatially contiguous.
Ideally I’d like to make use of SimEthereal’s sparse grid as a core zone data structure for spatially subdividing zones, in addition to using SimEthereal for realtime state synchronization. However, after digging around in the internals of SimEthereal it appears that only one EtherealHost is designed to run at once, meaning that keeping separate Ethereal spaces for each of my zones is out the window. If I added multiple EtherealHosts (one per zone - my zones, not Ethereal zones) to a single SpiderMonkey server I do not believe that there is any mechanism to prevent them from stepping on each others’ toes, unless I’m missing something.
Does anyone have any thoughts on how to deal with this?
There is another user who has managed to host several thousand players in his space game (that uses SimEthereal). I think it required some modifications but not many… in his case he also wanted to support multiple spaces but not across servers.
I think it was @zissis … but I meet a lot of folks here so I can’t always keep them all straight.
My apologies for the slow reply - the last few days have been pretty crazy.
In my case I really don’t see a way around multiple spaces, and I don’t see a good way around running multiple separate SimEthereal spaces on the same server. If you’re willing to consider supporting this in SimEthereal, I’d be willing to look into doing the work and making a PR. As far as I can tell, it would only require the addition of “ZoneSpaces” to the ZoneManager and the addition of space ids to the update messages. I haven’t investigated in detail, however, so I could very well be missing something.
I’m developing a distributed MMO server. The game world is split into a large number of zones, and every server runs some (varying) number of zones. Zones are given coordinates and thus can spatially neighbor each other, but the zones running on a server may not be neighbors - in other words, the server needs to assume that they do not have any spatial relationship. If all of the zones are simulated within the same SimEthereal “space” then they do have an implicit spatial relationship and it would be difficult to prevent a number of possible bugs that go along with that.
Okay. I can recognize that reasoning. Could you offset your spaces by some arbitrary large number and scale the units so you could fit every zone into SimEth?
Unfortunately no - each zone belongs to a specific “world” and all worlds are totally separate from each other and have no numeric coordinates associated with them. Many worlds can be run simultaneously within the same cluster. I suppose it might be possible to cram them all into the same SimEthereal space with some very clever string hashing, but that’s both difficult and fragile and at that point would probably be far more costly in development/maintenance time than simply adding multiple space support to SimEthereal.
The worlds are basically infinitely large sparse grids of 2x2x2 km zones. They are truly infinitely large, too - all zone coordinates are expressed as XYZ coordinates using Java’s BigInteger class, so it’s not hard to conceive of someone placing one at a coordinate outside of 64-bit range.
@pspeed is correct. I have thousands of concurrent users in my space game. I originally ran multiple instances of SimEthereal to get multiple spaces but have now switched to using the Z plane to achieve the same effect with zones. Easier to debug and works nicely.
Hint … nothing in the code prevents you from using different ports for each space and running multiple instances of SimEtheral in the same JVM. Each instance is self contained.
@zissis, thanks for the reply. The problem with using different ports is that then the number of network ports in use varies with the number of zone instances (my zones, not SimEthereal zones). It’s not a deal breaker per-se, but it’s hardly optimal since the zones move around between servers occasionally (and servers can spin up temporary zones on demand). In other words, which ports are in use on a physical server and how many are in use can vary significantly, which complicates provisioning quite a bit (firewalls, other services running on the same machine, etc.). It would be great if I could use a single TCP/UDP port pair.
Right now I don’t have time to address this, but I’m thinking when I have time I’ll fork SimEthereal to support this. I took a preliminary look at what it would take to make the modifications, and I don’t think it will be very hard. If/when I go this route I’d be happy to offer any changes I make back to @pspeed as a PR - I’m guessing others are going to want this kind of functionality sooner or later too.
I made the source code changes for that in my version initially. i used one port and overloaded the connection code. Single port and multiple instances of the stack. When the client connected it sent a packet to identify which instance it wanted and then I injected the connection to the apropriate instance of SimEthereal. I still use this code for the space station attack scenes … a battle scene per user’s space station that you attack. Thousands of scenes is the normal load for my game.