[Orion Elder]

Added: I never posted a poll, so I botched it. The poll is asking if you've ever used I3 or IMC2.

For those who have used one of those, do you like it? Why?

If you've used both, which do you like better? Why?

Thanks for the time.

[KaVir]

I've used IMC briefly (and installed it on GW, then later removed it). However I felt compelled to vote "OH GOD MY LEG FELL OFF", simply because it was so amusing, so you may need to adjust your poll accordingly.

[Orion Elder]

Oh, I expected as much.

[Terloch]

I've never used any kind of IMC, mainly because I have enough global channels that I don't really like as it is, let alone having another one which spams me more. Nor have I really ever seen the use for it on my mud, back when I had some close friends who were running their own muds I might have wanted to, but now, nah...

[Zhamel]

I agree with Terloch, on my mud there too may global channels already. I have wanted to get IMC for a while so I can talk with friends on other muds. Best use for this would be for Admins to discuss things about muds.

[Eagleon]

I think it would be great if more people used this, more regularly. I think it's an excellent idea. You could do all sorts of fun stuff with it if more people used it, like discuss ideas, and, uh... roleplay... and... Yeah. It's cool. I've used it before.

[Samson]

Sorta goes without saying that I've used them since I'm leading the development on both of the current Diku versions of these protocols.

The main obstacle I see right now with IMC2 is that it isn't a free connect system. You have to go through a number of steps to get connected to the network, which generally makes people less likely to want to bother. So to that end, I'm looking into ways to remove that barrier for those who would like to use it.

Main problem with I3 is that it just isn't very well known yet in the Diku community. With any luck this will change soon.

In the end though, it boils down to a matter of preference. There really isn't a great deal of difference in the fundamental operation of either protocol. However, I3 does offer more potential for expansion of features and is generally more stable.

Once you get past all that, it can be quite alot of fun to play with. And it's also a great way to discuss ideas with other admins ( and to some extent players as well ) as well as a place to find community support.

[Trax]

IMC2 0.10 to 2.00, Installed it, used it, administered a hub for it, coded for it (a bit) uninstalled it.

I3, installed it, uninstalled barely used as I'd decided to quit from InterMUD Comms soon after (no fault of I3 or IMC2 in that respect)

InterMUD Comms is a good idea (which is why I originally joined) although not to the point of use for roleplay, just a seperate chat system. It does have its flaws (what doesn't!) usually in implementation, but for keeping in touch and sharing ideas when you don't want multiple sessions open all over the place, I did find it useful.

[Yui Unifex]

IMO, if an intermud communication system is going to be successful, it's got to act more like a server and less like a passive client. It should be simple to turn on/off by the administrator and players, and simple for any hubs to accept and sever connections to the network.

I like IRC's model, where you have different channels that can be joined. If channel lists would be updated with the hubs in a distributed manner, there would be no problem with too much spam on the "main" channel, as the administrator (or even players) could move amongst them as they please. This would solve most of the problems I'm seeing in this thread, where people are afraid of the spam or lack of groups they'd get =).

[cronel]

I don't know IMC2. I've worked with I3.

My opinion on it is that it's nice, but it would be nicer if it was finished. Many parts of the protocol are only suggested. Among them some of the weirdest functions like the OOB stuff, but also something like how would two routers talk to each other. This sort of hurts it, because the protocol looks "abandoned".

[Orion Elder]

WOO! A discussion! As far as the channels go (everyone keeps worrying about the spam) the spam is minimal. You only get spammed if you choose to 'listen' to a certain channel. If you don't want to talk, or it gets too spammy just turn it off... that's what most do.

Another key difference between I3 and IMC2 is that the administrators of IMC2 like to try to 'censor' people. One of the reasons I've resorted to sticking with I3 most of all (no one tries to tell me I can't say something there, and if they do I just tell them to f**k off. ). I3, also, seems to be more stable (less service interruption, though the interruption is still there occasionally ... but as with ANY net based service, that's to be expected), as well as more versatile.

*shrug*

I'm just glad a discussion is developing. As for IMC, most of the versions I've used (1.0X - 2.whatever) have been majorly flawed with their channel refreshes... it can take anywhere from 30 seconds to almost 10 minutes for all the channels to refresh. I3 refreshes in under a minute, for me every time.

The other thing that really irks me is that IMC2 claims to be minimally code invasive. After stripping the code hooks from my code (thanks again, Samson) the code was reduced by about 680 lines. While compared to the total source that isn't a lot, for something that claims it only affects the startup, shutdown, and whatever files... that's a pretty good bit. Not to mention the LOADS of helpfiles (most of which are outdated and totally useless, not to mention as cryptic as the Minotaur's labyrinth), and the command entries in the commands.dat file.

Could just be me, though.

[Yui Unifex]

Originally Posted by (Orion Elder @ Sometime) administrators of XXXX like to try to 'censor' people

Any node should have complete control over one thing: The connections to that node.  So if a root node wishes to 'censor' someone, they must sever the connection to that person, or the node they connect to.

But root nodes are a bad idea, because then there's only one point of failure for a DoS attack.  So there should be no one root, rather an index of hubs that communicate as equals in a distributed manner.

Originally Posted by (Orion Elder @ Sometime later) ...it can take anywhere from 30 seconds to almost 10 minutes for all the channels to refresh. I3 refreshes in under a minute, for me every time

What is a channel refresh?  Is that where servers send an aggregate list of channels, or individual channel creation/destruction notices?

Originally Posted by (Orion Elder @ Sometime later still) stripping the code hooks from my code (thanks again, Samson) the code was reduced by about 680 lines

Maybe I'm misinterpreting... but do you mean 680 lines of hooks in your own code??  A hook for something so simple should be no more than the sum of the receiving and sending callback setters.  Easily less than 20 lines for a complex protocol.

[Orion Elder]

I was speaking of censorship, however. This is on channels where people can turn on and off a channel at will... *shrug* Just my opinion that if you don't like what you're seeing, when it comes to something like IMC2 or I3, turn off the channel.

As for channel refreshes, for each MUD to use a channel it has to 'subscribe' to the hub/reouter/whatever that controls said channel. With IMC2 said refreshes can take up to 10 minutes (it refreshes one channel at a time, at spaced intervals, with about 8 different channels total). I3 subscribes the MUD to those within less than a minute for ALL channels.

Stripping everything from the MUD source (not the IMC source, which I had in a total different directory) reduced the lines of code by a count of about 680. This means all the additions to the character data structure, among other things. This does NOT include the helpfiles (for opinions see above), or the command calls.

And I agree, the code SHOULD be less invasive (as it CLAIMS it is), however it's not. 680 lines of code is a pretty good bit, at least in my opinion, for something that is only supposed to affect the startup, shutdown, etc. files (this coming from http://www.mudworld.org/IMC/imcstory.php3).

[Samson]

Censorship. *shudder* Not good, and yet supported by the IMC administration ( well, not ALL of it anyway, since I *AM* an administrator ). I for one have never been a supporter of such things. I agree with Orion, if you don't like what you hear, turn it off. People are far too sensative these days. This is the main reason I prefer to use I3 over IMC. I have yet to see anyone booted from the network in all the time I've been on it, and they can get REALLY "crude" with their language.

As for the invasiveness, older versions of IMC prior to 3.00 stuck themselves into all sorts of places, including attaching to board/note code. I've managed to reduce this considerably with 3.00. Sure, the function of WHERE the hooks go hasn't changed, but it's far simpler to hook a function call in rather than plaster the actual function someplace it really didn't need to go. And I can obviously vouch for Orion's case. I removed tons of IMC code for him. He was running an older copy

[Yui Unifex]

Originally Posted by (Orion Elder @ foo) As for channel refreshes, for each MUD to use a channel it has to 'subscribe' to the hub/reouter/whatever that controls said channel. With IMC2 said refreshes can take up to 10 minutes (it refreshes one channel at a time, at spaced intervals, with about 8 different channels total). I3 subscribes the MUD to those within less than a minute for ALL channels.

So then an individual channel subscription is a refresh? Do you mean to say that each (un)subscription is propogated through the network less than instantaneously? Why?

Originally Posted by (Orion Elder @ bar) Stripping everything from the MUD source (not the IMC source, which I had in a total different directory) reduced the lines of code by a count of about 680.

Ohh, I meant specific hooks. Something like:
[code] #include <library.h>
/* on the receiving end... */
set_received_channel_subscription_callback(channel _subscribed);
set_received_channel_unsubscription_callback(chann el_unsubscribed);
set_received_message_callback(message_received);

/* on the sending end... */
send_channel_subscription(channel_name);
send_channel_unsubscription(channel_name);
send_message(channel_name, from_user, message);[/quote]

Where each callback has a specific functional interface. I don't mean the callbacks themselves, that could be as complex as you want it to be =).

[Samson]

Originally Posted by (Orion Elder @ foo) As for channel refreshes, for each MUD to use a channel it has to 'subscribe' to the hub/reouter/whatever that controls said channel. With IMC2 said refreshes can take up to 10 minutes (it refreshes one channel at a time, at spaced intervals, with about 8 different channels total). I3 subscribes the MUD to those within less than a minute for ALL channels.

Originally Posted by (Yui Unifex @ April 21 2002,11:38 am) So then an individual channel subscription is a refresh? Do you mean to say that each (un)subscription is propogated through the network less than instantaneously? Why?

Erm. Not quite. What happens is this. When an IMC mud connects to the hub, for any reason, it sends an even to the hub telling it to deliver the first channel "refresh" after 30 seconds. What then happens is the hub returns a pair of channels after the first 30 seconds. This "refreshes" the data for who owns it, moderates it, etc. Then IN THEORY the hub sends another pair down every 30 seconds until it's done. However, for reasons unknown, this fails to happen sometimes and the mud can be made to wait for as long as 10 minutes. And until a channel is refreshed, the mud simply can't use it.
This whole procees repeats even if the mud uses copyover, due to the nature of the protocol.

What sets I3 apart is that after it sends the initial startup_packet, it gets the startup_reply packet back within about 5-10 seconds. Shortly thereafter, the list of current channels is sent down to update the mud's list. BUT - the mud has a list of channels which are locally subscribed and these can be used from the moment that startup_reply comes back. No need to wait for the refresh. The advantage with this goes even further on muds equipped with copyover. The I3 socket can be passed as an argument to the execl() call and thus makes it available instantaneously after that's done, and even buffers incoming channel messages while the copyover is in progress.

[Yui Unifex]

Originally Posted by (Samson @ foo) When an IMC mud connects to the hub, for any reason, it sends an even to the hub telling it to deliver the first channel "refresh" after 30 seconds. What then happens is the hub returns a pair of channels after the first 30 seconds.

I see. But why does it refresh in pairs every 30 seconds, and not *all channels* instantly? I'm thinking that it should be very simple and automatic, for example:

1) A leaf server connects to another hub server.
2) Hub authenticates leaf.
3) Leaf sends all channel subscriptions.
4) Hub returns all channel information ('refreshes' it) it can provide.
5) If the hub doesn't have enough information to refresh the channel, it queries those that do know, or it queries all connections.

[Orion Elder]

I would guess it has to do with the way the channels were designed. They weren't, from what I understand (never actually looked at the channel code), designed very well.

I'm sure someone else (probably Samson) will probably elaborate more on this.

[funkalicious]

As it appears, OH MY GOD MY LEG FELL OFF has been bumped up into a two-way first place. Thats absolutely excellent. That means that 29.03% of the people who have taken this pole have only one leg.

[Samson]

I really couldn't say why it was done that way. Maybe to reduce spam or something, although I can't see that as being the case. Channel refreshes are sent every 30 seconds, regardless of whether they NEED to be or not. Anyone who administers a hub ( like me ) will be able to see this in the hub's logs. Obviously there's no valid reason for it to continuously send these out if the information isn't changing. Only thing it does is spam the network with needless packets.

[Orion Elder]

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.

[Yui Unifex]

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 =).

[Orion Elder]

*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.

[Samson]

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.

[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.

[Samson]

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.

[Trax]

Originally Posted by (Samson @ April 25 2002,09:30 am) Now all that needs to happen is to have the hubs act as servers for their muds and the main problem will be solved.

We'd be better off building again from scratch I think

[Sevoric]

I only use imc through the mud I work at. I wont mention. Its very resourceful when I come up with errors and/or problems. I currently am having a problem with my 'personal' smaug compiling, so I think any of the imc/i3 people that listen to imc should know who I am

[Yui Unifex]

Originally Posted by (Trax @ April 25 2002,04:15 am) 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.

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.

[Frakkle]

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