21 Apr, 2011, Rojan QDel wrote in the 1st comment:
Votes: 0
So I was playing with Amazon EC2 a bit the other day, and was curious if anyone had ever tried to run a MUD "in the cloud". Since that term is basically meaningless, I actually want to know if anyone has run a MUD server that is essentially able to be clustered so that rolling up another EC2 instance with the MUD would actually increase the performance. This would obviously require some serious reworking of a Smaug or Merc-based codebase, but some of the newer, fancier codebases might have this capability. Anyone ever tried to do it?
21 Apr, 2011, Runter wrote in the 2nd comment:
Votes: 0
I've tried using heroku. There's specific problems with heroku, though. I only was able to get about 15 seconds of mud out of it since long-running connections are killed by the heroku router after about 15 seconds. The problem could be solved on heroku using web sockets and pusher, but then it would no longer be free and that was the interesting thing about heroku for mud dev.
21 Apr, 2011, Rojan QDel wrote in the 3rd comment:
Votes: 0
Heh, I love Heroku for web apps. But I believe how they can afford to run so many Free clients is because they simply don't run them until someone hits the website. Isn't Ruby awesome?

But EC2 behaves more like a VPS than like Heroku, are there any distributed MUD servers that you could set up in essentially a load balancer sort of configuration?
21 Apr, 2011, Runter wrote in the 4th comment:
Votes: 0
Well, it's possible on heroku to run any type of app. The problem is connectivity to it. For example, you can push any Rack based app there. I did a simple test with a rack app that did nothing but loop sleep and print tick. Heroku doesn't stop your app from its autonomous processing when no http activity is going on. I think the simple answer to why Heroku is able to offer it for free is nobody uses it for anything other than web apps.
21 Apr, 2011, Idealiad wrote in the 5th comment:
Votes: 0
I don't know about load balancing, but you certainly could do something like sharding while allowing PCs to cross shards. Hopefully @Tyche ( :) ) will see this, but I think CoolMud is an example of a mud that allows some kind of distributed server setup?

http://www.mudbytes.net/file-711
22 Apr, 2011, David Haley wrote in the 6th comment:
Votes: 0
I don't think that "cloud" is the appropriate term here… if people mean distributed servers with shards and load-balancing, that is a little different from running an application on a massively distributed cloud platform, e.g., Google's AppEngine. Designing for a cloud like that is a rather different problem than designing for a cluster of shards.
22 Apr, 2011, Runter wrote in the 7th comment:
Votes: 0
David Haley said:
I don't think that "cloud" is the appropriate term here… if people mean distributed servers with shards and load-balancing, that is a little different from running an application on a massively distributed cloud platform, e.g., Google's AppEngine. Designing for a cloud like that is a rather different problem than designing for a cluster of shards.


What about EC2?
22 Apr, 2011, David Haley wrote in the 8th comment:
Votes: 0
As near as I can tell, EC2 gives you virtualized environments but environments nonetheless. AppEngine works differently: the server nodes/instances are invisible, deliberately so. I have to confess though that I'm not as well versed in EC2 as I am in AppEngine.
22 Apr, 2011, Runter wrote in the 9th comment:
Votes: 0
I know "cloud" isn't a very well thought out, or defined phrase. Some people just use it to mean anything "on the internet," but EC2 stands for "elastic cloud" and they, as well as heroku (which runs on it) claim to be cloud services.
22 Apr, 2011, David Haley wrote in the 10th comment:
Votes: 0
Yeah… cloud is definitely a very ambiguous term. But even with large, distributed systems, you have architectural differences. For example, AppEngine isn't designed to run long-duration processes like persistent servers. Yes, you have persistent data, and with persistent data, you can have transient handlers giving the impression of long-running servers. I don't know how EC2 does this w.r.t. its "instances". On AppEngine, there is no conception of instances or virtual machine environments or anything like that: just the CPU time/bandwidth/memory you consume.
23 Apr, 2011, Cratylus wrote in the 11th comment:
Votes: 0
David Haley said:
Yeah… cloud is definitely a very ambiguous term. But even with large, distributed systems, you have architectural differences. For example, AppEngine isn't designed to run long-duration processes like persistent servers. Yes, you have persistent data, and with persistent data, you can have transient handlers giving the impression of long-running servers. I don't know how EC2 does this w.r.t. its "instances". On AppEngine, there is no conception of instances or virtual machine environments or anything like that: just the CPU time/bandwidth/memory you consume.


you and sini should give me a cloud
23 Apr, 2011, Chris Bailey wrote in the 12th comment:
Votes: 0
@Cratylus - I don't think that it is appropriate to discuss getting cloud in this section of the forum. Maybe try controversial topics? Dragonballz fans and other children read this stuff man, keep it together.
23 Apr, 2011, RoFAdmin wrote in the 13th comment:
Votes: 0
Besides its Easter weekend, im pretty sure getting/giving clouds is not cool with the church on this weekend. Unless your a priest.
23 Apr, 2011, Rojan QDel wrote in the 14th comment:
Votes: 0
Heheheh….

Anyway, I realize that "cloud" is a loaded term, what I meant is a distributed server architecture so that you can spin up new MUD servers and ease the load on your other servers. From my understanding/playing with it a bit, EC2 essentially lets you propagate virtual machines based on a pre-defined image. Obviously it can get much fancier than that, but the core of it doesn't seem much different from something like Linode.
24 Apr, 2011, drifton wrote in the 15th comment:
Votes: 0
with ec2 you pay for a vm, and each computer can run something like 8+ vm's at a time. based on howmany cores the computer has, or what ever other metric amazon uses to deside its job balances, so its possible to run a mud on ec2, issues is that in general do to the limitations of telnet protocol and most mud clients it isn't possible to jump connections to another server with out help from the server the player originally connected to,
now if you wanted to do a distributed mud its possible, just not really practical unless you are doing something insane like simulating the life cycle of 5 million creatures in full on your mud
but it would consist of providing a gateway/portal mud server that all it did was pass info from mud node a, b, c and d to the client and passed the clients info back to those nodes
but i think it is fairly impractical.

are people pushing their servers with muds currently?
it seems weird to me that they would
24 Apr, 2011, David Haley wrote in the 16th comment:
Votes: 0
EC2, AppEngine, etc., are all just platforms. If you want a distributed MUD server such that you can seamlessly add server nodes, you need first and foremost a software architecture to allow that.
25 Apr, 2011, Rojan QDel wrote in the 17th comment:
Votes: 0
Exactly. My original question was really about whether anyone had written a MUD server that would benefit from having distributed parts.
25 Apr, 2011, Tyche wrote in the 18th comment:
Votes: 0
Idealiad said:
I don't know about load balancing, but you certainly could do something like sharding while allowing PCs to cross shards. Hopefully @Tyche ( :) ) will see this, but I think CoolMud is an example of a mud that allows some kind of distributed server setup?

http://www.mudbytes.net/file-711

Rojan QDel said:
Exactly. My original question was really about whether anyone had written a MUD server that would benefit from having distributed parts.


Marcus Ranum's UnterMud released in 1992 allowed cyberportals, a form of distributed mudding. While the HTTP protocol supports browser redirection that would allow load balancing, I don't know if there is much or any modern mud client support for automatic client redirection and reconnection. However, older clients such as tinytalk, tinywar, and tinyfugue supported a protocol of client redirection and reconnection called cyberportals. An Untermud cyberportal was an exit on the mud which pointed to another mud server. A message was sent to the client causing it to disconnect from the current mud and reconnect to the mud server pointed to by the exit. If the mud was another UnterMud the player object and their inventory was transferred to that mud. The player was ghosted (sent to a nowhere location) on the transferring mud.

Stephen White's CoolMud released in 1993 supported a fully distributed mud. Each mud server managed its own connections and required no special client supprt. Each server manages its own object database and communicates with other mud servers in a ring like network structure. This communication protocol was called YO. COOL the programming language supported distributed objects as well as runtime dynamic polymorphism and runtime dynamic inheritance. Code for a particular object executes on whatever server that object lives on. A player connecting to any mud in the network could move and interact with objects no mattera which server the object resided on.

Here is a sample of the code that implements an exit to another shard…
object #13@east
parents #7;

method init
name = "w;west";
leave = "You saunter west.";
oleave = "%n saunters west.";
oarrive = "%n comes in from the east.";
source = #12@east; // <— object identifiers are formed from a server unique object id and a server name.
dest = #12@west;
this.add_owner(#11);
endmethod
endobject


I couldn't find any prior work on distributed runtime dynamic object databases anywhere. And by anywhere, I mean to include work outside of muds!
Today, it would be fairly similar to Ruby DRb and Rinda (Linda), if anyone is familiar with those technologies.

If you are interested in whether anyone has written a distributed mud server, that should answer your question.
If you really want an answer as to whether someone has performed some prior analysis on benefits and/or performance, then I haven't seen it.
25 Apr, 2011, Rojan QDel wrote in the 19th comment:
Votes: 0
That's a really interesting answer, and something I've never heard of (Untermud). I'm not necessarily wondering about benefits/performance, just about whether someone has done it from a theoretical perspective.
30 Apr, 2011, Kelvin wrote in the 20th comment:
Votes: 0
As mentioned before, EC2 just lets you rent VMs on an hourly rate, much like Rackspace. We use both EC2 and Rackspace pretty extensively for customers and personal projects, and have found both to be just fine for MUDs and the web-heavy applications we develop at work. In the case of a MUD, we were most concerned about connection speed/quality, and both of these services are excellent here. Linode and other services would be just as fine, too. Even a virtualized server sharing time on a host machine will perform just fine for something like your typical MUD. Performance worries should be a thing of the past for most in the MUD world.

And as an addendum, unless you're just wanting to write a distributed game for the fun of it, it's not really something that is necessary in 99.999% of the cases for a MUD. KISS.
0.0/22