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