Kayle
Wizard


Group: Members
Posts: 979
Joined: Nov 27, 2006
|
#1 Posted Aug 28, 2008, 3:48 am
|
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.
|
......................... Owner/Coder Coder
Malevolent Whispers Star Wars: The Sith Wars
{Development Phase - Not accepting players} Open Alpha - Players Welcome - Full System Re-writes Imminent.
IMC2 Contact: Kayle@MW
FUSS Project Team Lead
SmaugMuds.Org - The Smaug MUDs Community Center
Last edited Aug 28, 2008, 4:55 am by Kayle
|
|
Kayle
Wizard


Group: Members
Posts: 979
Joined: Nov 27, 2006
|
#2 Posted Aug 28, 2008, 4:53 am
|
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.
|
......................... Owner/Coder Coder
Malevolent Whispers Star Wars: The Sith Wars
{Development Phase - Not accepting players} Open Alpha - Players Welcome - Full System Re-writes Imminent.
IMC2 Contact: Kayle@MW
FUSS Project Team Lead
SmaugMuds.Org - The Smaug MUDs Community Center
|
|
|
|
Kayle
Wizard


Group: Members
Posts: 979
Joined: Nov 27, 2006
|
#4 Posted Aug 28, 2008, 1:26 pm
|
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.
|
......................... Owner/Coder Coder
Malevolent Whispers Star Wars: The Sith Wars
{Development Phase - Not accepting players} Open Alpha - Players Welcome - Full System Re-writes Imminent.
IMC2 Contact: Kayle@MW
FUSS Project Team Lead
SmaugMuds.Org - The Smaug MUDs Community Center
|
|
|
|
|
|
David Haley
Wizard


Group: Members
Posts: 5,730
Joined: Jun 30, 2007
|
#7 Posted Aug 28, 2008, 5:14 pm
|
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?
|
|
|
|
|
|
|
|
|
|
|
mtfox
Apprentice

Group: Members
Posts: 19
Joined: Apr 7, 2007
|
#12 Posted Oct 24, 2008, 1:46 am
|
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.
Code (text): 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44 |
void imc_char_login( CHAR_DATA * ch )
{
char buf[SMST];
int gender, sex;
bool sent = FALSE;
if( !this_imcmud )
return;
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 );
return;
}
if( IMCPERM( ch ) < IMCPERM_MORT )
return;
snprintf( buf, SMST, "%s@%s", CH_IMCNAME( ch ), this_imcmud->localname );
gender = imc_get_ucache_gender( buf );
sex = dikutoimcgender( CH_IMCSEX( ch ) );
if( !IMCIS_SET( IMCFLAG( ch ), IMC_INVIS ) && IMCPERM( ch ) >= IMCPERM_IMM )
{
imc_send_ucache_update( CH_IMCNAME( ch ), sex );
sent = TRUE;
}
if( gender == sex )
return;
if (!(sent))
imc_send_ucache_update( CH_IMCNAME( ch ), sex );
imc_ucache_update( buf, sex );
}
|
Code (text): 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46 |
char *last_ucache_sent;
PFUN( imc_recv_ucache )
{
char gen[SMST];
int sex, gender;
DESCRIPTOR_DATA *d;
CHAR_DATA *ch;
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 )
continue;
#if !defined(IMCSTANDALONE)
/*
* Freaking stupid PC_DATA crap!
*/
if( IS_NPC( ch ) )
continue;
#endif
if( IMCIS_SET( IMCFLAG( ch ), IMC_NOTIFY ) )
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 )
return;
imc_ucache_update( q->from, gender );
}
|
along with the old flag and command for imc_notify
|
Last edited Oct 24, 2008, 2:47 am by mtfox
|
|
|
|
|
|
mtfox
Apprentice

Group: Members
Posts: 19
Joined: Apr 7, 2007
|
#15 Posted Oct 24, 2008, 12:32 pm
|
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].
|
Last edited Oct 24, 2008, 4:08 pm by mtfox
|
|