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.

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

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.

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.

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

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

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.

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

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.

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

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?

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

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.

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.

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.

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.

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.