Brainstorming: Things to make RunUO Better

[Ohms_Law]

In order to facilitate some general discussion and thought, i'm creating this thread. If there's something you would like to see changed and/or added, post it here as well with your thoughts. generally, in order to be usefull remember that its best to post the "who, what, when, where, why, and how" behind your ideas as much as possible.

Keep in mind that the thoughts and proposals in this thread are intended as forward planning. Nothing mentioned should be regarded as "this should be done now!" kind of thing. Also, keep in mind that this discussion is about changing the current RunUO core. It is not about discussing or supporting "my ultra leet custom core", as Zippy would say.


so, to kick this off, here are some of my thoughts.

Main as a Windows Service
Keep in mind that I'm talking about a rewrite of Main.cs (and everything that supports it), which implements both ServiceBase and ServiceInstaller.
Two other items would also be required. the first is a custom EventLog to store RunUO events separately from other application eventlogs. The second, of course, is a separate "front end" application to read and view the server's EventLog(s) and provide other interface functions (ServiceController type application).

here's some of the advantages that I see to doing this:

• Windows services are designed to be run continuously.
• Runs in a separate Windows Station. (lends stability. noone needs to login to the server to controll the service)
• Runs within its own security context. (plus, noone needs to login)
• no inherant interface = less resources. (should be anyway, even though the console really doesn't require much)
• Control. developing RunUO as a Windows Service allows separation of the functions performed by the program. subsystems could be implemented as separate services that run concurrently for one thing. further optimizations can be made with other .net framework tools (see below).

Disadvantages include:

• rewriting a large protion of some of the most basic code.
• a requirement to develop at least a basic interface as a separate program.
• larger "learning curve" for folks to install and use RunUO.

As you can see, there are some significant hurdles to doing this. however, I personally beleave that the ultimate payoff would be worth the time and effort.

Moving separate subsystems into there own space
using .net framework tools such as Application domains and the afore mentioned service structure, improvements and optimizations could be made which could include:

• improved stability. a single portion could be controlled individually. world saves, for instance, could be separated into its own process which could be started, stopped, paused, and adjusted on the fly without taking down the whole server. Of course, nothing can make a server 'crash proof', and failures in one subservice could of course still take an entire server offline. However, logical separations of functions could reduce these occurances to the bare minimum.
• performance. the inherant threading involved with running subsystems within their own processes sould improve performance in and of itself. however, having things somewhat separated could also lend itself to threading optimizations even further. having less syncronious operations to worry about should expose opertumities for threading.
• security. exposing only the portions of the server required to facilitate communication will improve security in and of itself. the ports and application domains required for logins, administration, web services, etc... could all be separated.

leveraging the Windows Service application model and AppDomains could possibly lead to some large performance gains and much improved security, in my opinion.
of couse, the same or similar disadvantages exist as above.

while significant time and effort in both development and user training exists in implementing all the above, some forward planning and good code practices could lead to a much better system as a whole. Basically, the thinking behind all of this is development of an "enterprise services" model program. If you adjust the view of RunUO as being a program that provides a emulation server to one that is simply a generic information server, as you read documentation regarding how to provide data services and communication you can start to visualize RunUO not as something programatically unique, but something very similar to what is widely available now in the windows world. Additionally, this view can lead to significant offloading of work onto the .net framework, which is running anyway. Leveraging the technology already provided by Microsoft, some savings could be realised in terms of lines of code and eventually even time updating or maintaining the code base.

A couple of less thought out ideas to leave you with:

• getting rid of world saves. moving the serialization engine to its own application space and a concurrent Service, world saves could possibly become continuous.
• World state: spawners and things such as quest systems behavior could be similarly offloaded. possibly, this could improve stability and performance, but more importantly control could be improved.
• interface. while having a separate program for interfacing with the server would be a pain to develop and maintain, it logically follows that much of the administrative duties could be offloaded from the UO client. separating the administrative functions from the client could also improve seurity.
• imagine the possibility of vastly improved web services, and perhaps if someone has the time and imagination, such additions as voice communications or IRC servers, UOAM type subsystems, etc...
• scalability. actually separating functions into real subsystems should lend itself well to scal issues. the "size" of a server should really be limited only by the availability of resources (which, it is for the most part. i'm refering to optimizing, not critisizing whats been done already).
• CodeDom. I redily admit that I know next to nothing about it, but it appears to me to be possible to move the server compiler to a CodeDom model, meaning MSIL code as well as support for Java and C++ in addition to the currently supported C# and VB? perhaps this could lead to a better definition of what a "script" is as compared to base application programming.

Anyway, these are some admittedly "pie in the sky" proposals, but I figure it can't hurt to discuss them.

besides, as Zippy said, its disapointing how little discussion occurs in these forums.

[Phantom]

Its already possible to use RunUO a service, doesn't require a code rewrite in the slighest.

I won't commit on your other ideas, I have my reasons...

[Ohms_Law]

Originally Posted by Greystar

Heh when I try to run RunUO as a service the service start ALWAYS times out before RunUO starts. I know the code already Exists in the Core, but what I don't know is how to make the services utility for XP be slightly more patient.

you can't, is a designed functionality of Windows that it waits for ( 30 seconds? ) for the service to start and reply to a message. thats part of the importance of writing a program that will be run as a service using ServiceBase.

[Phantom]

Originally Posted by Ohms_Law

you can't, is a designed functionality of Windows that it waits for ( 30 seconds? ) for the service to start and reply to a message. thats part of the importance of writing a program that will be run as a service using ServiceBase.

The service support was removed for a reason.

[Ohms_Law]

the intent behind this thread is to foster discussion. If there is a concern about a proposed change, its much more constructive to discuss the reasons why then simply stating that your dismissing any proposals out of hand.

also, there's no intent to confine discussion to what has already been posted. has a possible design change occured to you? lets here it!

[Phantom]

Originally Posted by Ohms_Law

the intent behind this thread is to foster discussion. I there is a concern about a proposed change, its much more constructive to discuss the reasons why then simply stating that your dismissing any proposals out of hand.

also, there's no intent to confine discussion to what has already been posted. has a possible design change occured to you? lets here it!

I didn't dismiss anything.

I said a fact the support for the service application was removed ( from the release ) for a very good reason. Since I didn't know the reason I didn't want to expand on it.

Plus its already possible to use runuo as a service.

[Zippy]

RunUO's original service support was written by me, and actually required no real changes to Main.cs.

As far as I know, all of those changes are still in the code, none have been removed.

How? Instead of implementing ServicesBase and Service Installer in Main.cs, a helper application was written which was in essence just a wrapper to start/stop/pause the runuo process and run it in the background.

Why? We felt at the time it was done that such major changes to Main.cs would be a bad thing. I still tend to think so. The way the Service classes are written, they simply do not integrate well into an application that still has the ability to run as a console, which may be important for runuo. Especially until a FrontEnd that is fully functional exists.

FrontEnd? Yes, I wrote one of those too, it was never completed (for various reasons) and the whole thing was pretty much abandoned. In the end I'm left with the question... other than a slight gain in convience what is the real use of spending a signifigant amount of development effort on making a RunUO service and frontend gui? RunUO is doing quite well as it is now... and I'm not sure there's really anything to gain from it.

Just my thoughts, I don't want to discourage anyone. But if someone is capable of undertaking this task, I can't help but wonder if their efforts might be better focused else where... like the AppDomains stuff discussed in the original post.

[Greystar]

I know of a couple of people who run their shards on dedicated servers at remote sites. However they are using helper programs like FireDaemon and other utilites to force RunUO to run as a service, mostly for the perpose of autorestart if the server itself where to shut down, how i got around that locally was just to place it in my StartUP folder but not everyone may have that option for one reason or another. I don't personally know of any real advantage to running it as a service as apposed to running it as a consol app as it stands now. Someone else might, but it works for me as is (the only thing I wish the RunUO had was a way to always restart in debug mode, weather it be after a crash or after an auto timed restart). I know that can be done with a core mod and I know the location to do it at, but I have yet to actually do it, just in case I ever need support, I try to stand clear of most Core Mods, except for the one with the extra person logged in thing, cause I was always like Huh there is no one else online.

[Phantom]

Just my thoughts, I don't want to discourage anyone. But if someone is capable of undertaking this task, I can't help but wonder if their efforts might be better focused else where... like the AppDomains stuff discussed in the original post.

I would have to agree, the part about there is other features that would be better use of time.

The number of people who had issues with the server feature, was a great number, it wasn't the best feature added to RunUO :-)

I know of a couple of people who run their shards on dedicated servers at remote sites. However they are using helper programs like FireDaemon and other utilites to force RunUO to run as a service, mostly for the perpose of autorestart if the server itself where to shut down, how i got around that locally was just to place it in my StartUP folder but not everyone may have that option for one reason or another.

Thats why I suggested that in my first post, I wanted to avoid making a comment on the other ideas, and I still won't. Doesn't mean I won't agree with somebody on them.

The next step in this idea(s) would be to actually do them. Create a plan and submit it to the community, you might get help from people, perhaps we could submit an entire system. I am speaking of the idea *Zippy" thinks would be a good thing to spend time on :wink:

Incase you can't tell Zippy comment put some interest into this AppDomain idea. Thinking of an idea that might or might not work, wouldn't mind talking to anyone interested in my idea.

A good website on material for appdomains: http://msdn.microsoft.com/vcsharp/pr...rp05162002.asp

[Ohms_Law]

Perfect example of the utility of changing to a Windows Service Model: loot macro need


Zippy, beem mucking around with main.cs reacently, and all the -service handling is still there. the problem is, all the rest of the code is written to utilize Console, as well as some other misc. things that are associated with Windows Stations (Desktop, user login, etc...)
I have to say that I find the argument that "Services don't have a user interface" to be simplistic. the user interface for a service is windows itself. the SCM to start, stop, pause, resume, etc... and the EventLog for things that would be written to the console.
That being said, I don't critisize your decision to go with a windows console app at all. As I stated in the other thread, spending the time getting a service up and running, with the ability to debuug it well, and being able to easily support RunUO without having to explain to every noob that come along that the server is running, you've just gotta start it... beleave me, I understand. however, there are advantages to running in the System space rather than from a user login. (mostly all spelled out in the original post).

the question of "what's really gained" is important though. I couldn't agree more that RunUO is doing quite well as it is. What is gained is really very dependant on how and where the server is run and where you are in relation to the server. if your running RunUO on a home computer, where you can login to windows and use/see the console at will... *shrug*, no problem. however, if you want to run a server on a colo'd system someplace, things can start looking different.
The other issue that I see is one of system and game administration. offloading most of the GM/Admin duties to something outside of client.exe can be nothing but a good thing, IMHO. security, control, robustness... all could be improved if administration were tied to something other than EA's client. one good example is what just reacently happened with handlers.cs and the "[" key. why should we be that beholden to EA's work on the client?
Anyway, I do have to admit that alot of this started as a "humm, wonder what I could do with this namespace" kind of thing. I've written Windows Service programs in C in the past (only one actual app that saw the light of day though), and I have to admit that the ease of creating them with C#/.net managed code is so stunningly easy that I was just looking for a reason to mess with it some more. however, I do think that It makes sence that RunUO ought to run as a service... Server applications are the reason 'de etre of windows service style applications, so its a logical conclusion.

edit: perfect example of the utility of a dedicated Frontend type app:
Flying Chimera

ok, enough talking from a soapbox. AppDomains.
let me leave yall with some reading materiel.
http://msdn.microsoft.com/library/de...iondomains.asp

AppDomains are somewhat,.. vaguely defined. I'm still trying to wrap my mind around it all myself, but the utility is obvious. I'm in the process of drawing a couple of diagrams that can help everyone visualize what I'm talking about, so bear with me some and I'll post them. I think that your right that effort tword utilizing appdomains could have higher payoffs in the end though.

[Ohms_Law]

just to keep yall from thinking that I haven't forgotten about this thread or anything, I figured that Id let you know that I've been reading every scarp of infor that I can find regarding AppDomains reacently. some really interesting stuff.
http://www.gotdotnet.com/team/clr/AppdomainFAQ.aspx
http://msdn.microsoft.com/library/de...rp05162002.asp
are a couple of the better articles that i've read so far. (although far from being the only ones).

basically, the ideas are gelling in my mind better now. its some hard studying, but anything worth it in the end takes time so doesn't bother me in the least.

what I see as possible ATM is basically splitting the RunUO code into several distinct Assemblies. one possible way to do this would be something like:
Server (basically as a DB 'backend', and overall control)
CodeDom Compiler (scripts that are loadable dynamically, anyone? ),
Serializer,
UO Client communicator (all the networking stuff specific to the client)
Web server type communicator (MyRunUO, etc...)
Admin communicator module (optional, I still think it would be better to dismount the admin/non game support GM functions to something other than the client).

that's basically what strikes me as logical without having really sat down and diagramming anything. which, incidentally, if anyone out there has diagrammed the core at all (be it simple drawings, something simply written out, or actual flowcharts) I'd appreciate it if you could point me in the right direction. the namespace diagrams and the code doc's that are currently available are great for there porpose, but inadequite for serious tooling about with the core.

anyway, the gist of this is that everything mentioned above would end up becoming what is normally thought of as a distinct application. however, for the most part, they would all run within the same process and use interman messaging and reflection to communicate between each other.

hopefully, much more to come later.

[Shaft]

I've been absent from the boards (and UO/RunUO as well) for quite a while, but would like to toss an extra $0.02 in here anyway. (Yeah, someone could buy a small house with all the two pence floating around here!)

I run a trillion things at one time -- a number of them service-based applications -- on my machine, and the one thing I'm always thankful for is that each server I run is either invisible to the desktop user or has a monitor that sits quietly in the icon tray. I know this sounds petty, but space on the taskbar is a major premium for me, and the last thing I want to do is run yet another application (unrelated third-party, no less) to hack the console window and taskbar icon bye-bye and replace it with a generic 16x16 in the icon tray.

While I don't necessarily see any major benefit to invoking RunUO as a service, I can understand why some people push for it: the standard is for service-based apps to run pretty much invisibly, and that's preferred for an app without a real UI that should always be running.

I personally see no benefit to running as a true service. If memory serves me correctly, it's just as easy to get an app to run at Windows start (not user login) as it is to start a service. (I've been doing platform independent work for far too long, so if I'm wrong, someone correct me.) So if the motivation for this debate is at all similar to mine, the real question becomes that of interface/visibility preference. That being the case, I think modifying the code to achieve said goal is much more feasable.

Thoughts?

[Ohms_Law]

well, there's third party utilities that will aloow you to start a normal winexe on system start, outside of a user login, just like a service, but there's no way to simply start a normal winexe without some kind of login. a service that runs a script (WSA) and performs an automated login is one method. the fact is though, the only method to run an app in windows when the system boots, without having somebody or something login and start it, is a windows service. I guess some (most) hosting sites have 24/7 staffing, but it seems sensable to me for the server to be as automated as possible.

but, its not that important. I've had my say on the subject.
weather anything ever comes of it or not... *shrug*

[Shaft]

Originally Posted by Ohms_Law

well, there's third party utilities that will aloow you to start a normal winexe on system start, outside of a user login, just like a service, but there's no way to simply start a normal winexe without some kind of login.

Au, contraire!

If this, combined with the hiding of the console window, are the only motivators for running as a service, I think maybe this brainstorm thread might be a succcess.

I couldn't remember the exact registry location, so I just did some digging to locate the specifics:

HKLM\Software\Microsoft\Windows\CurrentVersion\Run

Inserting a key name (any name unique to this location) and value (complete path and filename) launches the specified win binary at system startup, without a user login.

If a user doesn't have access to the registry, I can't see a case where they would be able to install an application as a service, either. If we can accomplish what we seek without modifying code, and without third-party utilities, I think that's the preferable route.

[Zippy]

There are simple work arounds for the console stuff, they are in the RemoteAdmin stuff in the scripts and in the core service stuff (redirecting console.Out to a memory stream which can be fed to a gui, etc)

[Ohms_Law]

Originally Posted by Shaft

If a user doesn't have access to the registry, I can't see a case where they would be able to install an application as a service, either. If we can accomplish what we seek without modifying code, and without third-party utilities, I think that's the preferable route.

this is all OT. the point of this whole excercise is to modify the core, but in a meaningfull and beneficial way.

implementing ServiceBase/ServiceInstaller is simply one suggestion, and its so easy to do in and of itself that I no longer think its that big of a deal. If Zippy wishes to do it, it only takes a couple of hours of work to do, so *shrug* I created an custom main.cs that included both and a custom EventLog in ~8 hours, and most of that was time spent reading up on how to do it in C#/.net vs oldschool C/C++. well, that and changing all the Colsole. calls to EventLog.

now, the appDomain stuff is a different story altogether...
that plus CodeDom. there more along the lines of what I was thinking about in the first place, as well.

[Shaft]

Originally Posted by Ohms_Law

this is all OT. the point of this whole excercise is to modify the core, but in a meaningfull and beneficial way.

Perhaps I should have been more observant of the thread location and original post when commenting. I scanned "things to make RunUO better" and applied my take, which from a this developer's standpoint is to avoid massive code overhauls when same/like functionality can be achieved with minimal editing. (This isn't to say "do it the shadetree way," but rather to evaluate and balance priorities.)

Originally Posted by Zippy

There are simple work arounds for the console stuff, they are in the RemoteAdmin stuff in the scripts and in the core service stuff (redirecting console.Out to a memory stream which can be fed to a gui, etc)

Zippy, I really appreciate this pointer. Once I get some tinker time, I'll delve into this a bit.

[Ravatar]

Originally Posted by Shaft

Au, contraire!

If this, combined with the hiding of the console window, are the only motivators for running as a service, I think maybe this brainstorm thread might be a succcess.

I couldn't remember the exact registry location, so I just did some digging to locate the specifics:

HKLM\Software\Microsoft\Windows\CurrentVersion\Run

Inserting a key name (any name unique to this location) and value (complete path and filename) launches the specified win binary at system startup, without a user login.

If a user doesn't have access to the registry, I can't see a case where they would be able to install an application as a service, either. If we can accomplish what we seek without modifying code, and without third-party utilities, I think that's the preferable route.

This *might* throw a SecurityException on the app, if the application requires more than the most basic amount of system rights.