|
|
|
|
|
|
|
|
|
|
Guest
Unregistered
|
#6 id:11515 Posted Aug 28, 2008, 5:09 pm
|
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.
|
|
|
David Haley
Wizard
Group: Members
Posts: 6,913
Joined: Jun 30, 2007
|
#7 id:11518 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?
|
|
|
Guest
Unregistered
|
#8 id:11520 Posted Aug 28, 2008, 5:25 pm
|
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.
|
|
|
|
|
|
|
|
|
mtfox
Apprentice
Group: Members
Posts: 19
Joined: Apr 7, 2007
|
#12 id:14313 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 id:14322 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
|
|
