Feature Request: String after finished up/download into chat

[Sascha]

Hello,
i need a feature that send a string like the $key command(only for hubsoftware visible) after finished download or upload a file, for example:
$UPL 7038484
upload size in bytes
or
$DWL 7038484
download size in bytes
With this information i can script for our registered user a top uploader or downloader list. We need this list to kick users that are only for leeching in the hub. Thx for your time to read this and i hope you can help us and other hub owners that have the same problem.

Greet Sascha

[sarf]

[snipped request for upload size reporting feature] With this information i can script for our registered user a top uploader or downloader list. We need this list to kick users that are only for leeching in the hub.

... if everyone uses your modified version that is, as well as not joining your hub with two extra-modified clients that report uploads to each other. Other than that, this is a nice idea, but since it will only mean more of a hassle to users ("You want me to upgrade my client so that you can get control of me? Get outta here!") and won't prevent the leechers with any knowledge (or knowledgable friends) that can modify the client, I'm afraid this won't be done. I'd be glad to tell you how to modify a client to do this, however, as it is quite easy.

Sarf.
---
Jake liked his women how he liked his kiwi fruit; firm yet yielding, sweet yet tart, and covered with short fuzzy brown hair.

[Sascha]

Hello Sarf, thx for your pm.
In our hub are only registered user from our board. We use dc for communication and to exchange project files/tutorials... . It is no problem that we decide that they take a special client. You are right, it is not easy to do this for a normal hub. The idea from a p2p program is "i give you something and i give it so some one other" and not "i take something from you, but no one from me". If every hub use this system, with some special controls in the hubsoft it is the best way for every fair user. Leecher can modify the client, but they can´t modify the hubsoft.
Greet Sascha

[sarf]

Hello Sarf, thx for your pm.

Not a problem. The idea has bounced around the boards before, so I just dredged up some old code (plus the fact that DC++ is really easy to extend in such minor matters such as this).

In our hub [there] are only registered user from our board. We use DC for communication and to exchange project files/tutorials... . It is no problem [for us to] decide that [the users need to have] a special client. You are right, it is not [as] easy to do this for a normal hub. The idea for a p2p program is "I give you something and I give it to some one else", not "I take something from you, but no one gets anything from me".

Yes, in your case this system would work quite fine, but since the hub software needs to be modified (since NM DC Hub scripts can't access commands - or am I mistaken?) this is not such a good idea unless someone "packages" a complete hub with easily used controls as to what ratio to have as a minimum and so on.

If every hub use this system, with some special controls in the hubsoft it is the best way for every fair user. Leecher can modify the client, but they can´t modify the hubsoft.

Yes, but the hubsoft need to take two modified clients reporting uploads to each other. The real disadvantage with this system compared to the rating system (which has been *extensively* discussed on the old boards) is that there is no positive feedback - a user does not get a bonus for uploading much data. Perhaps this should be added (requesting ratio from hub and prioritizing whom to upload to according to this) since then users would want to report their uploads. This would be better to handle in a stand-alone rating server so that many hubs could use the same rating server, thus allowing the user to migrate between hubs without having to build his/her "credibility" in every new hub.

Sarf
---
"Due to circumstances within our control, tomorrow will be cancelled."

[Sascha]

Good idea, but much traffic for one server. And what happens if rating server is down ?

[sarf]

Good idea, but much traffic for one server. And what happens if rating server is down ?

You don't get ratings. The ratings server should be seperate from the hubs (e.g. not placed on a computer with a hub), and you could solve the whole thing with a 50-100 bytes UDP-packet every time someone finishes an upload from you, thus giving quite a small number of packets. Shouldn't be too hard to handle.
When the ratings server is down you can't get/submit ratings. It's as simple as that. Then again, you could have several ratings servers.

Sarf
---
Vegetables are murder.

[mo2]

This is all good and fine, but do users really want a server holding all the network's upload/download activity?

Some may find the top uploading/downloading users and monitor them for illegal activity or whatnot?

I think this will be frowned upon.

[sarf]

This is all good and fine, but do users really want a server holding all the network's upload/download activity?

Some may find the top uploading/downloading users and monitor them for illegal activity or whatnot?

I think this will be frowned upon.

It is not a requirement that the information contains the IP of a user or indeed anything personal about that user - merely that there has to be some way (preferably securely) to identify a certain user. This identification should be exchanged during the handshake client-to-client.

I personally would not want any personal information to be stored on the ratings server - merely my rating and the data needed for successful (and secure) identification of myself. Perhaps a hash of the IP-number, the nick of the user or a mix of the two could be used.

Sarf
---
The more people I meet, the more I love my battleaxe.

[Sedulus]

Yes, in your case this system would work quite fine, but since the hub software needs to be modified (since NM DC Hub scripts can't access commands - or am I mistaken?) this is not such a good idea unless someone "packages" a complete hub with easily used controls as to what ratio to have as a minimum and so on.

you mean that nmdch doesn't pass unknown commands on to to scripts? that's incorrect, see:
http://dcpp.no-ip.com/dcext/

[sarf]

you mean that nmdch doesn't pass unknown commands on to to scripts? that's incorrect [snip]

Oh. Very well then, I wish anyone that tries to do trust management in scripts a very merry time.
On a more serious note I would recommend allowing people to have an upload/download ratio that is below one. This would allow people that have a normal client to get into the hub but will not allow them to stay there for very long. A few messages to that effect would be recommended (notifying people that they are below a specific upload/download ratio and that they will be kicked in a certain amount of time unless they produce some results. By the by, I'd recommend using IP/nick matching to prevent people from changing nicks and getting into the hub again. Just my five cents.

Sarf
---
One bright day in the middle of the night, two dead boys got up to fight.
Back to back they faced each other, drew their swords and shot each other.
A deaf policeman heard the noise. He came and shot those two dead boys.
If you don't believe this lie is true, ask the blind man, he saw it too!