28 Aug, 2008, Kayle wrote in the 1st comment:
Votes: 0
Following complaints received today about issues regarding the imcnotify command, I feel an investigation into it uses, and a search for a fix for said complaints is in order. Please bear with me as I conduct my all inclusive investigation.

Thank you.
28 Aug, 2008, Kayle wrote in the 2nd comment:
Votes: 0
Well, that investigation didn't take long at all.

As it turns out imcnotify is a huge resource and bandwidth hog. It takes up more resources and bandwidth then conversations on the network. After discussing it with Davion and Samson, I feel it's too expensive in resource and bandwidth costs for too little gain. Therefore imcnotify support will be suspended indefinitely. I won't say permanently because somewhere down the road we might discover a more efficient way of handling it, or something similar.

To those that use it, I apologize for any inconvenience this causes. To those that don't.. Well.. Um.. You might notice a drop in bandwidth usage by your IMC Client (assuming you monitor that) but won't notice anything otherwise.
28 Aug, 2008, David Haley wrote in the 3rd comment:
Votes: 0
How can this be using so much bandwidth? What all is it sending all the time?
28 Aug, 2008, Kayle wrote in the 4th comment:
Votes: 0
It's constantly sending. Even if there's no conversation going on, clients are still sending notification packets, and the servers still accept, parse and route the notification packets. The packets get sent to every client even if no one is using the notification stuff.
28 Aug, 2008, David Haley wrote in the 5th comment:
Votes: 0
Why, though? Why not send packets only when something actually happens, i.e. a person starts listening to a channel?
28 Aug, 2008, Guest wrote in the 6th comment:
Votes: 0
Because, simply put, there's enough activity of some sort out there for people to trigger "I'm not listening" and later the "I am listening" packets on a fairly constant basis. I've always made it pretty clear that the function is a source of endless network spam. I just never bothered to look into it very deeply. Kayle did, and found that it's really REALLY bad. Worse than I figured. Something on the order of 60% of the network's traffic is from channel-notify packets alone. That's just wrong. That exceeds even the keepalive-request packet, which is the second most used packet, and the is-alive packet which follows right behind keepalive-request.

So in the long run it's just better if the thing be removed from the client as a default feature and have it squashed at the server to stop the spam from spreading. The feature in and of itself was never ever a good idea anyway. I've regretted its implementation since day 1.
28 Aug, 2008, David Haley wrote in the 7th comment:
Votes: 0
Should these messages not be generated solely when somebody starts or stops listening to a channel? What kind of activity are you talking about? It is mind-boggling that this feature should be using 60% of the traffic. The fact that it talks more than keepalive/isalive is astonishing and to me pretty conclusive evidence that something is not right at all with the implementation…

Samson said:
The feature in and of itself was never ever a good idea anyway.

Well, if you disregard the network problem for a moment, I would tend to disagree… several people have it turned on. Well, we've been over this before. But in light of the networking problem: if that went away, why are you opposed to the feature?
28 Aug, 2008, Guest wrote in the 8th comment:
Votes: 0
Disregarding the network issues with it, I always thought it was just plain silly to burst notify the entire network that you're online. There's already a function in place for people to go "hmm, is Samson online?" and get a targeted response to that. Since that requires active use by a user, it doesn't clog up the network with traffic. The only reason it even got implemented at all was because Locke asked for it during a time long before MudBytes existed when we were trying to spread the code around into various codebase distributions and he agreed to do so if we implemented it for him. Turned out to be a waste of time as he never followed through and in fact never used IMC2 at all after I did the work. It sat around for eons in the client before someone else noticed it and told everyone about it. Hindsight etc. If I had yanked it back then it wouldn't be an issue now.
28 Aug, 2008, David Haley wrote in the 9th comment:
Votes: 0
Well, I really like the feature and would like to see it stay, network issues aside. There's a big difference between asking if a specific person is online and being notified when somebody new arrives. That's like saying you shouldn't want notification for new mail because you can keep going to the email window.

Anyhow, like I said, it doesn't make any sense for this to be using so much network traffic.
29 Aug, 2008, kiasyn wrote in the 10th comment:
Votes: 0
Knowing the (little) I do about the IMC2 protocol, it is very likely its not implemented very efficiently. But to update it would also mean updating all the clients… which can become a bit of a hassle.
29 Aug, 2008, David Haley wrote in the 11th comment:
Votes: 0
Isn't it kind of harsh though to completely disable the feature, thereby punishing everybody? You just modify the protocol to drop old, spammy versions, and keep the fixed, proper, non-bandwidth consuming version.
24 Oct, 2008, mtfox wrote in the 12th comment:
Votes: 0
Looking at the code, you could have it notify you when a ucache packet is sent. While ucache is only sent when the person is not in the ucache file of the mud they play on, and that is only cleaned after 30 days of non-use, this wont work very well, but at least it works some. If you could convince people to modify their send_uncache_update to send when someone logs in that is listening to any imc channel…… That would take care of 2 birds with 1 stone, instead of a completely separate packet for notify. To cut back on traffic for heavily played muds, we could make this only send every time an imm logged into their mud, as players are less likely to use imc.

void imc_char_login( CHAR_DATA * ch )
char buf[SMST];
int gender, sex;
bool sent = FALSE;

if( !this_imcmud )

imc_adjust_perms( ch );

if( imc_is_connected() == FALSE )
if( IMCPERM( ch ) >= IMCPERM_IMM )
imc_to_char( "~RAll IMC2 connections are down.\r\n", ch );


snprintf( buf, SMST, "%s@%s", CH_IMCNAME( ch ), this_imcmud->localname );
gender = imc_get_ucache_gender( buf );
sex = dikutoimcgender( CH_IMCSEX( ch ) );

imc_send_ucache_update( CH_IMCNAME( ch ), sex );
sent = TRUE;

if( gender == sex )

if (!(sent))
imc_send_ucache_update( CH_IMCNAME( ch ), sex );

imc_ucache_update( buf, sex );

char *last_ucache_sent;

PFUN( imc_recv_ucache )
char gen[SMST];
int sex, gender;

imc_getData( gen, "gender", packet );
gender = atoi( gen );

sex = imc_get_ucache_gender( q->from );

if (!(last_ucache_sent) || strcasecmp(last_ucache_sent, q->from) )
for( d = first_descriptor; d; d = d->next )
ch = d->original ? d->original : d->character;

if( !ch || d->connected != CON_PLAYING )

#if !defined(IMCSTANDALONE)
* Freaking stupid PC_DATA crap!
if( IS_NPC( ch ) )

imc_printf( ch, "~C%s has logged into %s.\r\n", imc_nameof( q->from ), imc_mudof( q->from ) );
last_ucache_sent = IMCSTRALLOC( q->from );

if( sex == gender )

imc_ucache_update( q->from, gender );

along with the old flag and command for imc_notify
24 Oct, 2008, quixadhal wrote in the 13th comment:
Votes: 0
The overall purpose of the feature is to notify people when someone joins or leaves a channel, right?

It seems to me that such notifications could be done instantaneously on the local MUD, but cached and sent in a batch to the remote IMC network. I mean, why should the whole network need to know every time someone logs all their alts in for 30 seconds? OTOH, it is good to know when your friend logs in to play, and it seems like a batch send every 5 or 10 minutes shouldn't be much traffic.
24 Oct, 2008, David Haley wrote in the 14th comment:
Votes: 0
I still don't understand why sending what is basically just a name over the network consumes so much bandwidth…
24 Oct, 2008, mtfox wrote in the 15th comment:
Votes: 0
I believe it was sending a packet for each channel a person had turned on, every time they logged in. Then another packet when they changed listening status to any channel. Now add that to the server having to send those packets out to every mud connected to them, yes it would be a lot of traffic to the server, considering how often those people actually use IMC. To cut back I propose it send all channels turned on along with the ucache, all in one packet. To cut back even more, I propose it only send the information every time an imm logs in. I just don't see pchat used enough to spend bandwidth sending packets for players. Like I heard the other day, and have had my players do the same…. The most common feedback from players is "How do I turn inews off?" Then again, we are sending ucache packets for people that are not even listening to imc…. If we could convince the server admins to drop the server side of channel-notify back in, I am sure we could come up with a less spammy way to send notifys for the newer clients. Hopefully leading to declined channel-notify spam in the future, yet still leaving the option open for those that wish to use it now.

Fri Oct 24 14:51:27 2008 :: IMC: Packet received: Darneth@Apothica 1224877532 Apothica!Kit
sune1 user-cache *@* gender=0 channels="game inews ichat imud_gossip"

Darneth has logged into Apothica, and is listening to [game inews ichat imud_gossip].
26 Oct, 2008, mtfox wrote in the 16th comment:
Votes: 0
I am not sure what the complaints were, but was curious about the bandwidth, and if a format like this would help out?
IMC: Packet received: Marlin@Apothica 1224990961 Apothica!Server01 channel-notify *@* join="Server01:ichat Server01:pchat Server01:ibuild Server02:icode Server02:inews Server02:irc Server02:imusic Server02:ivent "

of course just change the join to an exit for leaving multiple channels at once.
maybe something in the config for listening for notifys, so the server wont send to the mud unless notify is on?
26 Oct, 2008, David Haley wrote in the 17th comment:
Votes: 0
I think the problem was that it was (IMO partially incorrectly) concluded that it used up too much bandwidth. A study was done to count how many packets were notify packets, and a lot were. It was then concluded that the system was very wasteful. I think that the idleness of IMC was not accounted for: given how many people log on and off, and how things are quiet for very long periods of time, it's not surprising that there are lots of notification packets.

Nonetheless, it's quite possible that the notify system as-is (as-was?) is far too packet-happy, especially if it's sending a packet per channel. Sending one packet per channel should be fine, and a format like you propose sounds fine as well.
26 Oct, 2008, Kayle wrote in the 18th comment:
Votes: 0
I appreciate the work you're putting into this Marlin, but at the moment, this isn't something we're actively looking for a solution for.