Once upon a time there was a notification

Once upon a time there was a notification and it caused hubs to be ‘flooded’ by DC++…

When you are changing your slots, or share, or… anything that is contained in a $MyINFO, DC++ will send a new $MyINFO, indicating a change of your client information.

This notification means that every hub you are on will receive an arbitrary amount of data. If people are sending this information only once in a while, like every hour or so, the hub will no problem with the bandwidth being used.

Mostly, this isn’t a problem. Joining/parting of hubs is done seldom on a regular basis. Slot changes follow in the same scheme since there isn’t much point in constantly changing your slots, unless you need to obey hub rules about hub/slot count, which is rather bound to joining and parting a hub. The automatic refresh in DC++ will (as default) kick in every hour, so that obey rather nicely with our “like every hour so” scheme. Plus, how often do you sit and press ‘Ctrl+E’ to refresh the share?

However, as someone may note by now, my assertions of the refresh timing are just that; Assertions. Meaning that (1) the “auto refresh” value is configurable and (2) someone might want to refresh their share often when a friend is after some specific set of files.

When a refresh is initiated in DC++, DC++ will go through the folders that are shared and see if some file is added or removed and then act upon it. Then DC++ will, if anything in the share changed, notify the hubs by sending a notification, as I said above.

If we apply this to our hourly notification, this isn’t a problem. However, if we apply it to a low value for “auto refresh” and/or a frequent manual refresh triggering, we got ourselves a problem.

Like, if you have automatic refresh set to ‘2’, DC++ will refresh the share every two minutes, and assuming that you have a constantly changing share, DC++ will send a notification every two minutes to every hub. Many hub owners probably say now “hell no. I’m going to complain!”. Well, don’t. You see, it used to be like that. And may I assure you, there were complaints.

Instead, a new scheme for notifications in DC++ was written, explicitly focusing on the share.

This new scheme meant that DC++ will keep track of when it sent the last notification. Since DC++ keep track of when the last notification was sent, it can choose to not send a $MyINFO if the last one was too close to the current one. This time can be found in the creation of $MyINFO in DC++, and it is 15 minutes (give or take a few seconds, depending on some internal function stuff).

In essence, this is how DC++ decide if it should send a notification;
myinfo = everything about $MyINFO that DC++ is to send out, except the share
myinfo_share = the share info
if the last myinfo is different from the current myinfo; send the $MyINFO, or
if the last myinfo_share is different from the current myinfo_share and it has elapsed 15 minutes; send the $MyINFO
Note that this means that the 15 minute barrier does not apply if eg the slots change.

Also, note that this type of ‘cleverness’ by DC++, concerning the share, does not apply to ADC hubs; Only NMDC are affected by this.

Before someone comment “so does this mean that people can’t see my newly added files, if I refresh more often than 15 minutes apart?” No, it does not. This have no effect on your file list generation. It is only the notification for hubs (in other words, the hub window’s user list).

Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: