Distributed Server Idea

Damilis · #1 10-09-2005, 08:47 AM

Hmmm. Work is boring so i have been brainstorming:

Idea: Now I understand that the idea has potential security problems not to mention the myriad of other issues that result from distributed computing, but what if....

...Someone where to alter the zone.exe compile so that it doesn't rely on an external config file (db.ini)/start arguments. aka, all the settings are internal internal and external IPs, db connection, db userid, db password, port numbers, etc. This would be done so that people can register to receive a customized zone.exe that they can execute on there own PC but have it log into a remote world.exe. This way a distributed style EQEmu server could be created.

Issues that I can see up front:
-The MySQL server would have to have a damn fast connection.
-The remotely located zone.exes would have to have a decently fast connection.
-Even hard coding the settings still presents a security risk for the DB.
-Uptime now becomes less quantifiable due to the expect large range of PCs the Zone.exes will be running on.

Okay... yalls turn... good idea? Bad idea? Idea that needs a little work, but could work?

**cavedude** · #2 10-09-2005, 09:18 AM

You can already run world and zone on different machines, even over the net. I do it myself all the time. You just need to point the zones to the IP of the machine world is on. Then, you need to allow access of the zone server to the MySQL database. (I usually limit it to user/pass AND IP) You're still at risk by opening MySQL to the net, and there is nothing you can really do about that.

Your idea still suffers from the problem of if that single world server goes down, that's it until it's back up.

Also, by distributing pre-modified versions of zone, you'd pretty much have to open the MySQL server to everybody instead of a select few which is a big NO NO.

Damilis · #3 10-09-2005, 09:36 AM

Hmmm, I though that zone.exe wont run without the db.ini file in the same directory...which means you just handed out a username and password to the database. if you custom code each zone.exe to have individual userid/passwords and then set MySQL to accept only a specific userid/password on a specific IP (with the exception of packet sniffing or decompiling) shouldn't that secure the setup?

and yeah, the world.exe thing has me thinking... possible to code in a 'look for backup world.exe' into zone? hmmm.

sdabbs65 · #4 10-09-2005, 01:46 PM

Quote:

Originally Posted by Damilis

Hmmm. Work is boring so i have been brainstorming:

Idea: Now I understand that the idea has potential security problems not to mention the myriad of other issues that result from distributed computing, but what if....

...Someone where to alter the zone.exe compile so that it doesn't rely on an external config file (db.ini)/start arguments. aka, all the settings are internal internal and external IPs, db connection, db userid, db password, port numbers, etc. This would be done so that people can register to receive a customized zone.exe that they can execute on there own PC but have it log into a remote world.exe. This way a distributed style EQEmu server could be created.

Issues that I can see up front:
-The MySQL server would have to have a damn fast connection.
-The remotely located zone.exes would have to have a decently fast connection.
-Even hard coding the settings still presents a security risk for the DB.
-Uptime now becomes less quantifiable due to the expect large range of PCs the Zone.exes will be running on.

Okay... yalls turn... good idea? Bad idea? Idea that needs a little work, but could work?

I think it would be Very laggy even with a dedicated sql and world server.
the loading time for a zone would be thu the roof.
I might be wrong but it seems like a lot of wasted bandwith for nothing to me.
and theres no real reason to have off site zones they take up very little cpu and memory unless it's a big zone like GD.

now if you get a memory leak... they do lock up the server.

Damilis · #5 10-09-2005, 01:54 PM

Quote:

Originally Posted by sdabbs65

...and theres no real reason to have off site zones they take up very little cpu and memory unless it's a big zone like GD.

now if you get a memory leak... they do lock up the server.

Yeah, load times would be kinda heinous.

I have been trying to research the 'average system resources used' for minilogin.exe, world.exe and zone.exe and haven't come up with many benchmarks (that I can find) so I started benchmarking my own. I noticed that after a few zone ins and zone outs, a zone.exe will use anywhere from 10MB to 75MB of memory, which can add up fast.
Anyone else benchmarking there rigs?

Belfedia · #6 10-09-2005, 05:19 PM

On my linux box, i can say all Antonica zone static (78 zones) = 880 mb

**fathernitwit** · #7 10-09-2005, 03:19 PM

peq runs between 120 and 150 zones and has 2GB of ram. it looks like the old memory leak problems which plauged dynamic zones for a long time is gone, but world is still leaking some (at 120Mb after a week). None of our zones are over 35Mb of memory right now. Mysql has a couple hundred megs as well.

Damilis · #8 10-11-2005, 10:47 PM

Quote:

Originally Posted by fathernitwit

peq runs between 120 and 150 zones and has 2GB of ram. it looks like the old memory leak problems which plauged dynamic zones for a long time is gone, but world is still leaking some (at 120Mb after a week). None of our zones are over 35Mb of memory right now. Mysql has a couple hundred megs as well.

Hmm. Good data point. You're running a *nix box right? All zones dyno or some dyno some static?

johane · #9 10-12-2005, 11:29 AM

Quote:

Originally Posted by fathernitwit

peq runs between 120 and 150 zones and has 2GB of ram. it looks like the old memory leak problems which plauged dynamic zones for a long time is gone, but world is still leaking some (at 120Mb after a week). None of our zones are over 35Mb of memory right now. Mysql has a couple hundred megs as well.

I was just about to set up world under valgrind, with zone(s) under windows and my kids flogging the server as hard as possible in order to track these things down when we had our roof wrecked by a hailstorm. This has put my plans a little behind schedule. We're still waiting for the State Emergency Service to arrive, as we have a lot of holes still...

lucliner · #10 10-10-2005, 09:52 AM

I think what he is talking about is that each player would have a zone.exe ran from their computer assigned specificaly for them. when they zone, their zone server changes to the new zone, instead of the server holding the zone.exe, this is a great idea to reduce lag I presume, and to assure that the zones are up, but I doubt the idea is plausable, simply because the zone.exe controlls how the user/zone interaction takes place. if a "smart" player was to somehow modify that exe, then he could make anything possible on his side. It's best to keep all the server files exactly what they are... "Server" files. it makes no sense to make a server file run on the client.... and has huge problems with doing so... mainly compatability issues. Nice try, and keep brainstorming, you'll eventually get a good idea

Damilis · #11 10-10-2005, 12:57 PM

Quote:

Originally Posted by lucliner

I think what he is talking about is that each player would have a zone.exe ran from their computer assigned specificaly for them. when they zone, their zone server changes to the new zone, instead of the server holding the zone.exe, this is a great idea to reduce lag I presume, and to assure that the zones are up, but I doubt the idea is plausable, simply because the zone.exe controlls how the user/zone interaction takes place. if a "smart" player was to somehow modify that exe, then he could make anything possible on his side. It's best to keep all the server files exactly what they are... "Server" files. it makes no sense to make a server file run on the client.... and has huge problems with doing so... mainly compatability issues.

Well actually, no, this is not what I ment. I was merely contemplating the possible configurations of the .exe's I mean, if the .exe's weren't able/designed to be placed on different machines... why do you have to enter localhost(127.0.0.1) all over the .ini's?

Quote:

Originally Posted by lucliner

Nice try, and keep brainstorming, you'll eventually get a good idea

Well since emotion is so hard to read in text, I will give the benefit of the doubt and go with the idea that you weren't being an egotistical d**khead and getting in a cheap jab.