04-24-2002, 09:00 AM | #21 |
Senior Member
Join Date: Apr 2002
Posts: 346
|
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. |
04-24-2002, 09:39 AM | #22 |
Senior Member
|
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 =). |
04-24-2002, 09:47 AM | #23 |
Senior Member
Join Date: Apr 2002
Posts: 346
|
*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.
|
04-24-2002, 05:36 PM | #24 |
Member
Join Date: Apr 2002
Location: United Socialist States of America
Home MUD: SmaugMuds.org
Home MUD: Arthmoor MUD Hosting
Posts: 249
|
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.
|
04-25-2002, 04:15 AM | #25 |
New Member
|
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. |
04-25-2002, 04:30 AM | #26 |
Member
Join Date: Apr 2002
Location: United Socialist States of America
Home MUD: SmaugMuds.org
Home MUD: Arthmoor MUD Hosting
Posts: 249
|
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.
|
04-25-2002, 04:48 AM | #27 |
New Member
|
|
04-25-2002, 05:48 AM | #28 |
Member
Join Date: Apr 2002
Posts: 41
|
|
04-25-2002, 07:31 AM | #29 |
Senior Member
|
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. |
04-25-2002, 10:05 AM | #30 |
New Member
Join Date: Apr 2002
Posts: 4
|
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 |
04-25-2002, 10:30 AM | #31 |
Senior Member
Join Date: Apr 2002
Posts: 346
|
|
05-20-2002, 01:17 PM | #32 |
Member
Join Date: May 2002
Location: Linköping, Sweden
Posts: 31
|
|
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 |
|
|