Live port dev vs. live/builder port dichotomy?
Goto page Previous  1, 2
 
Post new topic   Reply to topic    mudlab.org Forum Index -> Design
View previous topic :: View next topic  
Author Message
Molly O'Hara



Joined: 11 May 2005
Posts: 99
Location: Sweden

PostPosted: Tue Jun 07, 2005 9:51 pm    Post subject: Reply with quote

Tyche wrote;
Quote:
If one's building or script code is crashing the mud, I'd sure hate to see the game code.

Ah but Kjartan has apparently added a single flag and has a somewhat different experience. Imagine if one actually added a role-based security system instead of level-based one. Imagine if one had object ownership. Imagine if one weren't running an Dikumud and didn't have a piss poor security model.


I probably should get insulted because Tyche implies that my Mud has a shitty code, hehe.

But I won’t, partly because he is one of my favourite posters, and partly because he does have a point there. I am totally aware that crashes and bugs that can get exploited are the fault of the Admin for not fixing the code enough to prevent it. But a fact is that creating a free mud is not like a regular job, it’s something you are doing on your spare time and sometimes you code or build when you should rather be sleeping. People are only human, errors do occur, we can’t be everywhere. But what we can do is to minimise the consequences of those errors as much as possible, at least in the Gameport.

As for our code, it is a patchwork, a problem I think we share with most Diku derivatives. I guess that anyone starting a codebase from scratch, like Thraithe apparently is doing, has the upper hand there. But for most of us, we are stuck with our more or less heavily modified Diku based code. And a discussion like this hopefully isn’t limited to Thraithe’s specific conditions, I’d like to think that we can discuss general problem from a less restricted viewpoint.

Now about our code; at the time when we first started our buildport it probably WAS rather shitty. Over the years it has been improved, added to, rewritten, cleaned up, and during all this time the gameport had to be kept up and running. The code is pretty stable and efficient now, most of the crash bugs have been eliminated, and the same thing goes for the DG_scripts we use. But the code is still a patchwork, only a much larger one now. And every time a batch of new code gets put in, we always get a short period of memory leaks, bugs and sometimes even crashes, until everything has been debugged and it is stable again.

As for our security model it certainly isn’t piss poor. We do have task-based command groups, not level-based. We do restrain our builders from editing – and even entering – any other zone but the one they are assigned to. We do have a flag to close a zone for players until it is approved. We don’t have any of the opened gameport zones in the buildport, so nobody can use their imm commands there to check out an existing zone. And naturally we never ‘overwrite’ the content of the gameport with that in the Buildport, or any other Port for that matter. What we overwrite is one single zone, when we transfer an approved zone from the Buildport to the Gameport for the final testplaying (during which of course it is of course still disconnected from the rest of the world).

And I am not so sure that Kjartan had a 'somewhat different experience'. What he actually wrote was this;

Quote:
I think it's just not that big a deal that someone gets caught cheating and then we get rid of them. Probably half of our content was created by people who were eventually thrown out for cheating. It doesn't mean it's bad content, much of it is very nice. We have good logs and good search tools so we can usually undo the effects of their cheating without too much effort.

To answer your original question, if someone builds a lot of stuff and doesn't cheat, (or only cheats once, gets chewed out, and then stops), then we decide we trust them. We're often wrong; but it never has done us any real harm. In fact, once in the early days of the mud someone stole our source code (as has happened several more times since then) <snip>


It is things like this we want to avoid, by having separate Ports. Sure we can undo the effects of cheating, but why risk them happening in the first place if you can avoid it? As it is the Builders have a full set of OLC commands and full freedom to experiment in the Buildport, but nothing goes into the Game Port without first being checked in file by me or another Head Builder.

And sure - occasionally things still slip past the control. Because we are all human...
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Author Message
Kjartan



Joined: 13 May 2005
Posts: 110

PostPosted: Tue Jun 07, 2005 10:00 pm    Post subject: Reply with quote

Here's a description of our security model. As Tyche pointed out, this started from a diku with a very simple model: four immortal levels (immortal = a catchall for builder, coder, admin, quest runner, whatever), with more commands accruing at each level. None of us like coding security stuff - in fact we will often just say "we'll accept the possibility of cheating rather than add this additional security which will be annoying" - but here's the stuff we at some point felt we couldn't do without:

1. complete logs of everything, stored in a manner that requires root access to the game server to alter; only one guy has such access.
2. "approved" flags and a "who approved this" string attached to rooms, objects, and mobs.
3. the ability to grant specific immortal commands to individuals who aren't at the necessary level for that command, e.g. some trusted players can remove player abilities to use public channels

A fourth thing that is very important, although I'm not the paragon of it, is not to take it personally when your immortals (or outsiders) cheat, steal your code, pan you on TMC, DOS you, steal your passwords and break into your email accounts, or whatever. This too shall pass.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Kyuss



Joined: 13 May 2005
Posts: 37
Location: Southern Hellinois

PostPosted: Tue Jun 07, 2005 10:35 pm    Post subject: Reply with quote

Yeah that is the failing of DIKU code over all is the patch work involed in it.

Dont worry about your code Molly, if the Soul code every got out, Id
have people emailing me for months in laughter at some segments of my
stuff. Hell even I laugh at my own stuff now and again.

Sometimes Im even shocked it boots up. This is amazingly shocking as of
all of the coders who trashed the code to high heaven and low hells from
between 96 and 2000 before I got stuck coding.

Im realllly shocked that it doesnt leak memory like the Titanic after striking
an iceberg. I still havent figured that one out. (knock on wood).

No I dont run a test Port, I do all the coding on the live port. The mortals
dont mind it if it crashes sometimes, the mob growth over time makes
mobs really really sick when its been up 3-4 days at a time.

All in all, I do love Diku, even if it is an old pair of jeans that is nothing
but patches holding the patches together.

log("leaving autopost - thank Vom");
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
Author Message
Myrd



Joined: 08 Jun 2005
Posts: 4

PostPosted: Wed Jun 08, 2005 5:31 am    Post subject: Sandboxing Reply with quote

I am for the Builder Port model.

The fact is, builders generally have access to way more commands than regular mortals, and since these commands are usually more powerful (ie they allow to change the state of the world in many different ways), and less thoroughly tested (there's more players doing player things than builders using builder commands), there is a greater chance that these commands will have bugs that could crash the game or do other bad things. Obviously, once discovered these crashes should be fixed, but you always run with the possibility of something going wrong.

A builder port is a sort of sand box that would prevent such things from causing real harm. While you can put lots of effort into making the live port secure, with multiple levels of priveleges and what not, this will still not ensure absolute security from bad things (neither will a builder port, but it will do a much better job at it), and you would be spending tons of time implementing the system when you could be coding the Next Great Features for Players.

Also, the builder port is a place to experiment. Obviously, you can make a sandbox environment on the live port, but the more complex things you want to put into the sandbox, the more effort it would take to implement it. For example, let's say your MUD supports AI-driven kingdoms, that are editable by builders. If you want to introduce a new kingdom that's really powerful and that will start sending its knights throughout the world and you want to see if they're too powerful or not, you don't want to do this on a live port (unless you have a giant sandbox on the liveport that would be a copy of the world but then you might as well use a builder port).

Obviously, there are technical reasons that favour implementation of one or the other system. For example, Diku with flat world files is easy to manage with a build port. But the PostgreSQL example that someone posted here isn't. I'd say it can still be done for that scenario, you just have to separate your stuff into two databases: static world (made by builders), and dynamic stuff (players, dynamic world stuff, etc). Then, keep the dynamic database always running, but swap the static builder one during updates from the builder port. That should do it, if you want to go with a Builder Port design.
Back to top
View user's profile Send private message
Author Message
Molly O'Hara



Joined: 11 May 2005
Posts: 99
Location: Sweden

PostPosted: Wed Jun 08, 2005 7:44 am    Post subject: Reply with quote

Kjartan wrote
Quote:
A fourth thing that is very important, although I'm not the paragon of it, is not to take it personally when your immortals (or outsiders) cheat, steal your code, pan you on TMC, DOS you, steal your passwords and break into your email accounts, or whatever. This too shall pass.


R*O*F*L
Yeah well, you are obviously a better person than I am, Kjartan, I tend to take all those things rather personally. Laughing

You know what the real funny thing about that comment is?
Our Buildport is not only in a different Port, it's on a different server. The mud itself runs off one of our old coder's personal computers, but the buildport, as well as our website, are hosted on a public, commercial server, called mu-host.com. Don't ask me why, it was the coder's decision, but my guess is that it was for security reasons. We are pretty anal when it comes to security, after some disgruntled players who were also hackers (or rather script kiddies) DDOSed the mud some years ago.

And here comes the funny part. Lately both the Buildport and the Website have been down a lot, due to server problems. And only today did I get the explanation for that, when a letter arrived from the server people, saying among other things, the following.

Quote:

For the past three months we have received constant DOS (Denial Of
Service) and DDOS (Distributed DOS) attacks from a variety of sources,
most of them coming from APNIC (Asia Pacific Network Information Center)
which distributes IP numbers to countries such as China, Taiwan,
Australia, New Zeeland, to mention a few. Most of the attacks have
originated from Hong Kong, China, and Taiwan.

And no, we haven't accidentally run over someone's cat or relative.


Well, maybe it wasn't all that funny, but it had me laughing at least.
And no doubt This too shall pass...
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Author Message
Tyche



Joined: 13 May 2005
Posts: 176
Location: Ohio, USA

PostPosted: Wed Jun 08, 2005 5:03 pm    Post subject: Reply with quote

Molly O'Hara wrote:

But for most of us, we are stuck with our more or less heavily modified Diku based code. And a discussion like this hopefully isn’t limited to Thraithe’s specific conditions, I’d like to think that we can discuss general problem from a less restricted viewpoint.


That's too bad, but I think you really mean a more restricted view as opposed to an unrestricted view. I don't see any danger whatsoever that the Diku derivative viewpoint is not being adequately represented here. One might argue it's been way over represented on mud forums to the point where innovation is stifled because of those design assumptions.

There are many mud servers that allow pretty much anyone to code and build on the same port as the player port that have uptimes measured in months not hours or days. Perhaps they were designed with humans in mind.
Back to top
View user's profile Send private message Visit poster's website
Author Message
Kyuss



Joined: 13 May 2005
Posts: 37
Location: Southern Hellinois

PostPosted: Wed Jun 08, 2005 7:38 pm    Post subject: Reply with quote

I saw the Soulcode stay up for 11 days once, but this year I havent seen it
stay up past 6 days. A month, lol, lands would the players complain.

I of course would have to be out of state for this occurence.

Nice dream to shoot for though.
Back to top
View user's profile Send private message Send e-mail Visit poster's website Yahoo Messenger MSN Messenger
Author Message
Jimorie



Joined: 18 May 2005
Posts: 10
Location: Gothenbrg, Sweden

PostPosted: Wed Jun 08, 2005 7:48 pm    Post subject: Reply with quote

Tyche wrote:
One might argue it [Diku] has been way over represented on mud forums to the point where innovation is stifled because of those design assumptions.


Very true in my opinion.

As for the topic, I think having only one server where all work and playing is done is the favorable choice - if you can assure that some of the more important points already raised do not apply to you, or atleast shouldn't apply that often... With the important points being foremost security and stability. Developers shouldn't be able to cheat and get away with it, and buggy code shouldn't be able to crash the server. I think having a staff of trusted people goes a long way for both of this. And of course, the fundamental implementation of the server matters. I guess if you run a bigger mud with a partly unproven staff, a secondary port might seem like a good idea.
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    mudlab.org Forum Index -> Design All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Powered by phpBB © 2001, 2002 phpBB Group
BBTech Template by © 2003-04 MDesign