Quote:
|
The problem is that there is no way to set a zone server to use any specific port when a zone crashes and restarts. It will just use the next available one, but I don't think it ever uses the same one it was on before.
Unfortunately, this means that there is no way in the current system for me to setup my servers to run zones on both of them without risking zones being unavailable due to being on the wrong port. I am going to make a post in the bugs section about the launcher_zones table port setting being completely pointless. I am also going to make a feature request for an entry in the config file to let it set port assignment per zone server. Code:
<zones> I think that would be the simplest solution. And again, once I get this all worked out, I will write up a nice guide in the wiki for it. I hope I don't get mattmeck'd (tm) for making double posts! This post here is for support, the bug post I am going to make is to get the ports issue filed as a bug and the feature request post is the one to request a new setting in the config file. IMO, those are all separate even though they do all relate to this one same issue. Maybe posting the right things in the right places will get them looked at by the right people. |
What happens is when a zone crashes, it restarts on the next highest zone port above the last one used. I had dynamic zones boot from the zonew (World Server) 1st on ports 7000 thru 7004. I logged in and zoned into a dynamic zone and crashed the zone. When it restarted it was on port 7011 which was the next zone number in the queue so to speak. I crashed it again and it restarted on 7012... AND both times it restarted on the zonez server where it was originally on the zonew server. but... I was still able to get into the zone because port 7011 was forwarded to the server with zonez where it restarted.... So, it appears to restart on the next port in line and on the last zone server used.
It just keeps getting better..... |
Ya, if I wanted to run all dynamic zones, this wouldn't be an issue. The reason I am setting this up in the first place is because one of my raid zones gets over 20 players quite often and on the world server, it is too much for it to handle and it crashes ALOT! I am sure this is more than a little annoying to my players. So, I am setting it and 4 other heavy traffic zones to run on my main PC which has much more ram and a faster CPU. This should increase overall stability by a great amount and maybe even let me have more players on my server. So, I need to have static zones setup to run on the zone server. I don't want to just split the dynamics between servers.
The problem is if I set a zone to static, and no matter what port I actually start it on (before or after the dynamics on the world server are all loaded), I can get it working fine. But as soon as it crashes, the zone will have a big risk of starting on the wrong port dynamically and since it is specified in the launcher_zones table to launch that static zone on my secondary zone server, it will be unavailable to players. Now, this issue wouldn't be too bad if my zones stayed up all of the time. I am sure the ones on my zone server PC would be pretty stable there. But, I use a zone resetter quest script that I wrote to reset each of these zones after they have been up a certain number of hours. Nexus is set to reset after 4 hours, which is basically restarted the same as if the zone had crashed. I need the zone resetter to deal with the player ghosts issue that apparently only occurs on Windows. |
It seems that the only way to make this really work, is that it has to be changed in the code.
Does anyone know what the zone_server table is for in the DB? I added in a zone there and it picked up the last_alive time, so it's in the code some where. Seems you could edit in the zones and port and have the code look at what port the zone is supposed to be on and reload with that port number? Wondering why we haven't heard from any of the Ops who run multi-servers? |
I PM'd Cavedude directly and this is what he had to say about it:
Quote:
|
Quote:
|
We run all of our zones from one server, so I honestly have zero experience with this zone_servers issue.
As far as junctions (as they're called in NTFS) to network shares, it can be done with LSE (Link Shell Extensions). http://schinagl.priv.at/nt/hardlinks...kshellext.html Basically, you'll want to make c:\eqemu\quests pull from s:\eqemu\quests (where s:\ is a mapped network drive). Dax |
As a follow up to this thread, I wanted to make note that I have contacted all major servers and found that none of them other than PEQ use multiple zone servers. The only one I didn't check with that might be using it is Dragon Soul, which is a Chinese server.
So, it seems that this feature isn't very useful until some change is made to the code that will allow the world server to assign port ranges per zone server. If I can ever get to a state where I understand code well enough, I might try a crack at getting this added into the source. But, right now that is a ways off. If any other coders have a chance to look into this before then, I would greatly appreciate any feedback. I would mainly like to know if this would be something very complicated to change, or of this could be something that might not be too bad to add in. Hopefully this post will come in handy for someone considering multiple zone servers in the future. And maybe there will eventually be a fix to get this working :) |
Trevius,
Did you contact Rojadruid? Below is a post he made back in November of 2007. Although, I just tried to login to his sever and I just get booted back to the login screen. Quote:
|
Ahh, I knew I had read that exact message somewhere, but wasn't able to find it when I was looking for it.
I found these 2 related posts: http://www.eqemulator.net/forums/showthread.php?t=24754 http://www.eqemulator.net/forums/showthread.php?t=23916 I am PMing froglok23 and rojadruid in case either of them still read these forums and have any input into getting this working the way I want. My guess is that they got it setup and working, but that they never noticed that if a zone crashes, the world server doesn't know which port range to assign to which zone server. And that this causes the zone to be unavailable. I am trying to get a linux server up and running to see if it works any differently as far as multiple zone servers go. Windows definitely has issues as far as I have seen. The main problem is that the setting in the config for ports on the world server PC are the only ports that the world server will will ever create new zones on. So, even if you set a separate range of ports in the config on your zone only server, that port range pretty much just gets ignored. Hopefully one of the guys I am PMing will have a solution and will reply here or PM me with it. I would love to get this working. |
Quote:
|
Quote:
I did try that and it seemed even worse then running both the world and zones on the same PC. And for the record, the other PC I tried using as just a zone server is about double the stats of the server PC I have been running on and it was still unstable being only a zone server. I wish there was a way to share the load. I am trying to get a debian install of eqemu running, but mainly to see if it can help my resources and stability issues without having to do anything else. I have it almost ready to go accept for some reason it seems like the NPCs are hovering above the ground and it is hard to move around. I didn't get any errors when loading the world the last time I tried it so far. But I am definitely a novice with this setup. I don't even know if there is a way to watch the real time log entries echoed to the console similar to how it works on windows. The only thing that concerns me so far about the build is that I did get alot of warnings when I was compiling the eqemu source, but I didn't see any errors. I will leave those questions for another thread though, as I don't want to throw off the purpose of this one. |
All times are GMT -4. The time now is 02:23 PM. |
Powered by vBulletin®, Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.