Top Mud Sites Forum Return to TopMudSites.com
Go Back   Top Mud Sites Forum > Mud Development and Administration > MUD Coding
Click here to Register

Reply
 
Thread Tools
Old 04-24-2002, 09:00 AM   #21
Orion Elder
Senior Member
 
Join Date: Apr 2002
Posts: 346
Orion Elder is on a distinguished road
It would make more sense for the hubs to take connection requests instead of sending them out. This way, data is only sent when it absolutely needs to be.

For example:
[code]
if ( channel_exists && channel_running )
return;
else
send_channel_refresh_request( channel );
[/quote]

Just a thought.
Orion Elder is offline   Reply With Quote
Old 04-24-2002, 09:39 AM   #22
Yui Unifex
Senior Member
 
Join Date: Apr 2002
Location: Florida
Posts: 323
Yui Unifex is on a distinguished road
Send a message via ICQ to Yui Unifex Send a message via AIM to Yui Unifex
Question

There's a useful idiom among client/server models that deals with this sort of thing.  It basically states that the server should be passive, and the client should notify the server of state changes.  This is useful because it precludes the server from taking an active role in the maintenance of its clients, which prevents security and encapsulation problems.

It's good to remember that the server doesn't have to be completely passive (like an HTTP server), because it must still relay information between clients and provide for security issues arising from rogue clients.

So while the server would be keeping track of channel subscriptions for a particular mud, it would never resync this information if it wasn't at the client's request.  Therefore if the client doesn't refresh their channels it's your problem, not mine =).
Yui Unifex is offline   Reply With Quote
Old 04-24-2002, 09:47 AM   #23
Orion Elder
Senior Member
 
Join Date: Apr 2002
Posts: 346
Orion Elder is on a distinguished road
*nod* My point exactly. The people who WANT the channels are responsible for it, thus their systems should contact the hubs. Not the other way around.
Orion Elder is offline   Reply With Quote
Old 04-24-2002, 05:36 PM   #24
Samson
Member
 
Join Date: Apr 2002
Location: United Socialist States of America
Home MUD: SmaugMuds.org
Home MUD: Arthmoor MUD Hosting
Posts: 249
Samson is on a distinguished road
And I agree that it should be handled this way. Refreshes should only be sent upon the mud actually connecting to the hub. Unfortunately this isn't how it was actually handled, and it would require the simultaneous update of all of the hubs in the network to undo the problem. This isn't necessarily an easy thing to handle since hubs often use different versions of the code to start with.
Samson is offline   Reply With Quote
Old 04-25-2002, 04:15 AM   #25
Trax
New Member
 
Join Date: Apr 2002
Posts: 5
Trax is on a distinguished road
Send a message via ICQ to Trax
Definately channels should be a demand basis, within a client/server model. In IMC2's though case is that at present it (including IMC2 3.00 that Samson made) is still a peering system. Every mud has the capacity of being a hub, a system like I3 does not allow this. v3.00 has more constraints on it that no longer make this completely viable (Samson removed the capacity for multiple connections for one thing), but its still working under the networking assumption its a peering system, as most of the existing IMC2 network thinks as the bulk of them are still IMC2 v1-v2.00g implementation.

A client/server model would give you your central point of query, except with IMC2 when you distribute the channels across all the muds (muds having compiled in ICEd, the hosting side of the channels) there is technically no servers. Thus everyone is potentially a server and either everyone queries everyone else, or those few broadcast.
Trax is offline   Reply With Quote
Old 04-25-2002, 04:30 AM   #26
Samson
Member
 
Join Date: Apr 2002
Location: United Socialist States of America
Home MUD: SmaugMuds.org
Home MUD: Arthmoor MUD Hosting
Posts: 249
Samson is on a distinguished road
While it may be true that the underlying protocol is still operating on certain assumptions, it is no longer true that 3.00 muds can act as hubs. They don't have the capacity for it. As you point out, they are only allowed one connection. That one connection is outbound ONLY. The mud cannot accept inbound IMC connections from any source, including a hub, since there's no port set aside to listen for them. So even if the network as a whole is still assuming it to be a peering setup, the mud code is at least acting as a client-only connection. Now all that needs to happen is to have the hubs act as servers for their muds and the main problem will be solved.
Samson is offline   Reply With Quote
Old 04-25-2002, 04:48 AM   #27
Trax
New Member
 
Join Date: Apr 2002
Posts: 5
Trax is on a distinguished road
Send a message via ICQ to Trax
Trax is offline   Reply With Quote
Old 04-25-2002, 05:48 AM   #28
Sevoric
Member
 
Join Date: Apr 2002
Posts: 41
Sevoric is on a distinguished road
Post

Sevoric is offline   Reply With Quote
Old 04-25-2002, 07:31 AM   #29
Yui Unifex
Senior Member
 
Join Date: Apr 2002
Location: Florida
Posts: 323
Yui Unifex is on a distinguished road
Send a message via ICQ to Yui Unifex Send a message via AIM to Yui Unifex
Distributing the channels across all muds is probably the most preferable thing to do. And it's also a very easy thing to do with a top-down design and a client-server model using the idioms I mentioned.

When I say "client-server", I mean that one instance of the program acts like a client in some cases, and one instance acts like a server in some cases. Some instances will be more like a server than a client in that more people will connect to them (hubs), and some instances will act solely like clients (leafs). But I still think that the program should have support for both -- that a network should not be benevolantly dictated; instead existing as a collection of equals.

Actually, one can still gain a great deal of the benefits of the client-server model with a top-down distributed model. If every server knows its subscriptions and the subscriptions of those immediately connected to it, it can propogate information without having to query each time. All we have to do now is stack the subscriptions, so a leaf hub will tell the main hub all of the subscriptions of its clients. When information for that channel has been received, the hub will simply send to all clients (which are possibly other hubs) that need it. And it's robust in that if a hub is offline, as long as a leaf knows the address of another hub, it can simply reconnect there.

Now make that all automatic -- distribute a list of hubs and have clients ping for latency, and you've got quite a powerful network.
Yui Unifex is offline   Reply With Quote
Old 04-25-2002, 10:05 AM   #30
Frakkle
New Member
 
Join Date: Apr 2002
Posts: 4
Frakkle is on a distinguished road
Post

I didn't like it, probably because I could find no other muds who used it.

However may I recommend ABERCHAT.
It's a wonderful chat protocol, probably very similar to Intermud, but it has actively 9-13 muds on it.

It was originally designed only for AberMUDs but I adapted it over to Merc format (which is easily translated to Diku).

And I'd just love to see other Diku's connected to it... Hehe.

-Me
Frakkle is offline   Reply With Quote
Old 04-25-2002, 10:30 AM   #31
Orion Elder
Senior Member
 
Join Date: Apr 2002
Posts: 346
Orion Elder is on a distinguished road
Orion Elder is offline   Reply With Quote
Old 05-20-2002, 01:17 PM   #32
mhc
Member
 
Join Date: May 2002
Location: Linköping, Sweden
Posts: 31
mhc is on a distinguished road
mhc is offline   Reply With Quote
Reply


Thread Tools


InterMUD Communications Systems - Similar Threads
Thread Thread Starter Forum Replies Last Post
Intermud-3 network router cratylus MUD Announcements 0 07-24-2006 08:19 AM
InterMUD-3 for Java milliway MUD Coding 0 04-03-2005 12:30 AM
Mud Domain Intermud Communication Network Samson MUD Announcements 0 11-27-2004 03:14 AM
ICE-MAN InterMUD Network kris MUD Announcements 0 04-22-2004 04:19 PM
Intermud-3 Router Testing Samson MUD Coding 2 09-28-2003 12:40 PM

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

All times are GMT -4. The time now is 04:47 PM.


Powered by vBulletin® Version 3.6.7
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Style based on a design by Essilor
Copyright Top Mud Sites.com 2022