Gammon Software Solutions forum

See www.mushclient.com/spam for dealing with forum spam. Please read the MUSHclient FAQ!

Entire forum
Programming
General
Odd idea I had...

Home \| Users \| Search \| FAQ
Username:	Register forum user name
Password:	Forgotten password?

(New message)

Subject:	Odd idea I had...
Name:	Your forum user name. Register forum user name
Password:	Your forum password. Forgotten password?
Message:	[quote=Shadowfyr] Well. From my understanding DNS works like this: Local DNS checks its info for the adress, if not found then it tosses it up to a higher level that it knows has DNS ability, if that fail then it gets tossed again, ect. until you finally hit the master DNS. This is why some web sites can go awol when hosted through a DNS system that is not registered with those who techinically function as the master servers. As long as your own private DNS is working, it can redirect and resolve any links that you need, but if your hosting .hack sites and the people that normally register .com, .edu, etc. refuse to recognize and record that info (very likely, since you are not registering what they consider to be a 'valid' IP with 'them'), then when your DNS dies, so does any connection to all .hack addresses. So my theory, though untested, is that having each mud server also act as a DNS server, you should always be able to reach at least one server that recognizes the main host name of www.play.game, even if your normal server is offline. Though actually the address is backwards now that I look at it, it should have been like: 'www.play.game and www.mygame.game' or 'www.game.play and www.mygame.play'. In theory, based on the way the internet is 'supposed' to operate it should work. However with some servers intentionally redirecting traffic where it 'thinks' is more efficient, you now sometimes get entire sections of the internet becoming inaccessable from say the southern US, but still accessable from NY. The NY server may simply refuses to redirect traffic in a direction 'it' thinks is backwards compared to the origin of the message. It can take hours before a nearby system realizes a problem exists and then often someone in the middle of the alternate path will refuse to redirect the traffic anyway. It might be more efficient, but it is a bloody pain in the rear and is not even close to what the original design was 'supposed' to do. :p As for virus code or the like.. It would be more limiting, but you could design it so that weapons and skills where limited to specific parameters. In most cases a combat skill just emotes different than others. If it effects other things, then you can still do it, by exapanding the range of things that you can give it to effect, all without sending any code at all. Items are a bigger issue, but not a big one, since such an item will only exist in one 'real' instance on the new server, protections can be used to keep it from making copies of itself (or unlimited ones of something else) and to make sure it can only effect those things in the game you expect. I.e. if it isn't an immortal it shouldn't be able to access a nuke command and you can't carry a player object on your person, so it can't be immortal, etc. There are bound to be bugs that need to be worked out to keep malicious things from actually transitioning from system to system, but what it can do depends on what you allow it to do in the first place. You can't design the mud driver with the assumption that 'everything' on it is 100% trustworthy. This makes it potentially less flexible, but not by much. 90% of what anything does involves sending text out to people, the rest is changing stats or other such effects. As long as code is internally limited so it "can't" do anything more dangerous, all you need to worry about is permanently banning any item (or player if they show up again with something similar) that happens to do something you don't like. [/quote] Message to be posted (in English, please).
Forum codes:	Check this if your message uses 'forum codes' or templates (auto-detected for new posts). Forum codes Templates

Save this message ...

Subject review (reverse sequence)

Posted by

Ian Kirker (30 posts)

bio

Date

Thu 25 Sep 2003 12:37 PM (UTC) [ quote ]

Amended on Thu 25 Sep 2003 12:42 PM (UTC) by Ian Kirker

Message

Purely on an architecture principle, would this be at all relevant?

On Discworld MUD, and a large-ish list of other MUDs, we have connection to the I3 (Intermud) system, which allows communication between all the MUDs on the list. There's a chat channel that goes between, and from our mud at least, you can send tells, request finger info on players of other MUDs, and other things too. (Usually most of these features are restricted to high level players or creators, to keep the traffic down.)

There's the specification here: http://www.dasein.org/i3spec.jsp

In case you're interested.

-Ian

(Don't blame me, I'm just a player.)

top

Posted by

Shadowfyr USA (1,774 posts)

bio

Date

Fri 01 Aug 2003 (UTC) [ quote ]

Message

With the DNS. Not sure how it caches things. Some it might thrown out, but that is why you run your own DNS server. It is also why those that do run their own vanish if the server they have the DNS set up from goes down. It is safer to use valid registered IPs of a known type through the official sites for such registration, but not 100% necessary. The drawback is like you said, not having the odd DNS get cached or the like.

A central site won't work as I intended. You have to make sure that central site is there, that it is always up, that it properly redirects to everyone else. This is inconvenient in the least and fails completely to provide a true distributed system. You can run your own DNS though, you just pay a price doing it. By having each mud server recognize the 'main' link, but also resolve to the specific IPs of each server it knows, you don't need to worry about what is or isn't cached. Which ever one is closest will return the IP you want. I would be more worried about if the IP is cached, since then some local IP might continually return only the closest IP it last resolved and thus sending out a DNS request from the server itself would, instead of causing the request to bounce back from every mud that recognizes it, instead only resolving to your own mud.

The whole idea is to avoid a central server that if lost would take out the entire network and allow new muds to auto-link into the existing network of worlds. It may not matter though. Each new mud would automatically send out a DNS request the first time it starts and thus it could send its own IP and name out to what ever mud server actually responds, who cares which on it is, then from there the information could be automatically propigated like normal DNS servers do to the cache of all the other muds in the network. If you can't find someone elses, you just hop to one of the servers the one you connect to does know about and try looking for it there. One of them will know about the address, even if all of them don't yet have a complete list. This is more or less how DNS already works anyway, you just can't rely in this case on the normal caches, nor do you need to keep track of anything not in the list of domain types used by the muds. ;)

----

As for the mud I play at. It is Ages of Despair. They haven't yet gotten the main page back up, but the gateways at:

http://aod.mine.nu:4995/people/
http://aod.mine.nu:4995/gateways/player_page

Both work, since they are generated by the mud itself. The mud is running on MudOS with a modified TMI-2 LPC library. You would need to actually talk to one of the wizards to actually figure out how they make it work though, so... Of course the gateway code and the stuff making it work are probably part of the main MudOS server and the TMI-2 library, so you could look at those too, if you can find them. lol They are no longer being developed, so tracking down a download link might be a slight problem. lol Of course not as much of a pain as trying to compile or run the dang driver under Windows.

I am not real good at C, so never managed to do either of those things successfully. :( The precompiled version crashed, the source for Windows had a mess of things its Make file didn't do, wouldn't do right, etc. I finally decided it wasn't worth the frustration.

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}

top

Posted by

Torgny Sweden (15 posts)

bio

Date

Thu 31 Jul 2003 11:45 PM (UTC) [ quote ]

Message

Shadowfyr, I am not sure that the DNS idea will work, mostly since you need to identify the server as a MUD that's connected to the chain of nodes that serve the mud network. How are you going to do this? Randomly sniff all the servers in the DNS and see if they're MUDs?

You'd still need a list of all the game servers somehow to add them to your DNS as you call it. How are you else going to find them? I know, I am reiterating that. But it's a vital point.

I'd say that you could go for something of a hybrid. You still have a master server which all the nodes connect to once and again, and then a list is maintained at the server. When a node connects, it also retrieves a node list, so that it can contact other nodes if necessary. Of course, you could make all the mud nodes to be like the master server, in some kind of "linked list" so to speak, but I am not sure that such an idea would be optimal for performance and reliability.

"Eagles may soar, but weasels don't get sucked into jet engines!"

top

Posted by

Nick Gammon Australia (18,770 posts)

bio Forum Administrator

Date

Thu 31 Jul 2003 11:06 PM (UTC) [ quote ]

Message

Interesting concept, although I think using DNS servers is a slightly strange way to go. I think the DNS caching would throw you out.

However, a central server that supporting MUDs know about might be simpler.

Quote:

I might note that the http stuff is done. The one I play at specifically supports special gateways to provide a complete player list, finger info and some other general things from http.

Yes, I don't doubt that. What MUD is that? I would be interested to see how they have done it (reply by email if you prefer to keep it quiet). I think from memory that DoT has some sort of HTTP interface as well.

- Nick Gammon

www.gammon.com.au, www.mushclient.com

top

Posted by

Shadowfyr USA (1,774 posts)

bio

Date

Thu 31 Jul 2003 08:35 PM (UTC) [ quote ]

Message

Well. From my understanding DNS works like this:

Local DNS checks its info for the adress, if not found then it tosses it up to a higher level that it knows has DNS ability, if that fail then it gets tossed again, ect. until you finally hit the master DNS. This is why some web sites can go awol when hosted through a DNS system that is not registered with those who techinically function as the master servers. As long as your own private DNS is working, it can redirect and resolve any links that you need, but if your hosting .hack sites and the people that normally register .com, .edu, etc. refuse to recognize and record that info (very likely, since you are not registering what they consider to be a 'valid' IP with 'them'), then when your DNS dies, so does any connection to all .hack addresses.

So my theory, though untested, is that having each mud server also act as a DNS server, you should always be able to reach at least one server that recognizes the main host name of www.play.game, even if your normal server is offline. Though actually the address is backwards now that I look at it, it should have been like: 'www.play.game and www.mygame.game' or 'www.game.play and www.mygame.play'. In theory, based on the way the internet is 'supposed' to operate it should work.

However with some servers intentionally redirecting traffic where it 'thinks' is more efficient, you now sometimes get entire sections of the internet becoming inaccessable from say the southern US, but still accessable from NY. The NY server may simply refuses to redirect traffic in a direction 'it' thinks is backwards compared to the origin of the message. It can take hours before a nearby system realizes a problem exists and then often someone in the middle of the alternate path will refuse to redirect the traffic anyway. It might be more efficient, but it is a bloody pain in the rear and is not even close to what the original design was 'supposed' to do. :p

As for virus code or the like.. It would be more limiting, but you could design it so that weapons and skills where limited to specific parameters. In most cases a combat skill just emotes different than others. If it effects other things, then you can still do it, by exapanding the range of things that you can give it to effect, all without sending any code at all. Items are a bigger issue, but not a big one, since such an item will only exist in one 'real' instance on the new server, protections can be used to keep it from making copies of itself (or unlimited ones of something else) and to make sure it can only effect those things in the game you expect. I.e. if it isn't an immortal it shouldn't be able to access a nuke command and you can't carry a player object on your person, so it can't be immortal, etc.

There are bound to be bugs that need to be worked out to keep malicious things from actually transitioning from system to system, but what it can do depends on what you allow it to do in the first place. You can't design the mud driver with the assumption that 'everything' on it is 100% trustworthy. This makes it potentially less flexible, but not by much. 90% of what anything does involves sending text out to people, the rest is changing stats or other such effects. As long as code is internally limited so it "can't" do anything more dangerous, all you need to worry about is permanently banning any item (or player if they show up again with something similar) that happens to do something you don't like.

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}

top

Posted by

Torgny Sweden (15 posts)

bio

Date

Thu 31 Jul 2003 08:38 AM (UTC) [ quote ]

Message

Hey,

About the server connections, I think you haven't quite gotten down what a DNS does, as it will not really help us in this case at all. What we want is a master server that each mud node connects to and upon connection the master server stores their address, their types of modifications, and many other important aspects of their server. Once player A wants to move from server B to server D, server B will contact the master server, and if it is possible to execute a move, it will do it, and the two servers will do this through the master server.

I don't think that having transferable code copy over just because a player is moving from a mud extended with a player guild is necessarily such a brilliant idea. It's got possibilities, but imagine how easy it would be for just one of those nodes to spread a "virus" to all the other nodes by just moving their player around, thus spreading the infected code. What you'd need in that case was some sort of snippet repository where all master server approved snippets are stored, thus any MUD that has not got the particular snippet can install it instantly upon request from the master server. It'd probably need a nice and simple format, like an XML file along with a dynamic library file. The mud reads the XML, does some settings, and just links in the library file, which is of course coded according to a certain set of rules which allows for it to be linked in. Of course, the master server could still be tampered with, but the chances are lesser that way. Not so many windows to break.

It's a pretty good idea for a Sci-Fi mud, especially with larger areas of space-time, which could allow people to use "wormholes" to transport themselves between servers ("galaxies").

Bah. I haven't even had my morning coffee yet, and my headache's setting in, and look what you're having me doing... Replying to forum posts in the early dawn. ;) Off I go to hunt the caffeine beast.

"Eagles may soar, but weasels don't get sucked into jet engines!"

top

Posted by

Shadowfyr USA (1,774 posts)

bio

Date

Thu 31 Jul 2003 04:28 AM (UTC) [ quote ]

Message

Kind of happy this forum is here Nick. lol I noticed you comment about adding some sort of chat protocal thing or http for out process stuff. I might note that the http stuff is done. The one I play at specifically supports special gateways to provide a complete player list, finger info and some other general things from http. In fact, since they have yet to get the main page back up since the server was moved, these gatesways are the only thing on the site you can get to from a browser right now. lol

However, I had a much stranger idea. It hedges on keeping track of player stats, money, etc. as a % of some maximum. Why? So you can create a distributed system where the stats can be shifted to match changes made to a different version of it. The idea is this:

Mud A - Has a thieves guild.
Mud B - Has no such guild.

1. Player from A switches servers to B through a portal
2. Mud A sends B the code to handle the thieves guild (just for player stuff, they have to return to Mud A to advance, etc.), a file with the relative maximums, any special stuff for items carried and the players file.
3. Mud B adjusts the players stats to make them 'equivalent' to the mobs and players on their mud, including damage done,etc. No the player can wander around in this new world.

The real trick is this. Provide each copy of the mud with DNS lookup ability. This lookup for a new player would be something like: www.play.game

Now assuming I am right about how this work, your client will send out a DNS request which will be responded to by the first place that returns a valid address. The address would be a redirect, like www.play.myworld. From them on you can log into there, however the server itself could send out requests every so often and since more than one DNS response may come back, it should in theory collect a list of servers that support the design. A request sent to those servers would also return a name and some general info, like races available, guilds hosted there, etc. This would even work for a browser, since connecting on port 80 could cause the muds gateway to display a page for which ever site first responded, but could provide a similar list of alternates and info on them. Same with associated forums, etc.

This could let someone make one mud with a few hundred rooms and actually end up linking themselves into a network of muds that could collectively have millions of rooms. Saving the character is an issue info is an issue, but it should be possible to have it send the packet to save back to the server they normally log into, same if they go linkdead or anything short of a crash happens and saving the info is necessary. A second option is to allow some muds to act as super nodes that can save backup copies of data for the smaller ones, so even complete disaster or the closing of a mud won't necessarilly permanently destory someones character.

Just figured I should post this idea some place before I forget it.

Oh, and in case you are wondering, I sort of got the idea by watching too much 'hack//.sign' and thinking about the logistics of such a system where different servers contain otherwise disconnected sections of a world that simply won't fit on one server. ;) Of course keeping some fool from making a sci-fi mud and having a draconnian barbarian with a hellsword show up is an issue, but... lol

main {
__if (Schrodinger_Cat is Alive or version >= "XP"){
____if version = "Vista" then Performance /= Number_of_Cores;
____call Functional_Code();}
__else
____call Crash_Windows();}

top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

3,018 views.

Reply to this subject Start a new subject Refresh page

Go to topic: Search the forum

top

Comments to: Gammon Software support
Forum RSS feed ( http://www.gammon.com.au/rss/forum.xml )