Upload reporting...

A private forum for us Super-Humans, I even trust you to be able to edit your own posts =)

Moderator: Moderators

Locked
arnetheduck
The Creator Himself
Posts: 296
Joined: 2003-01-02 17:15

Upload reporting...

Post by arnetheduck » 2003-04-11 09:18

Hm, there was a veeery long thread about user stats and upload reporting some time ago, mainly with sarf and volkris discussing the ins and outs...I read the first 40 screenful, but then I ran out of online-time so...
Anyway, the way I see it, the easiest way to do things is to let DC++ send a little string to the hub after each finished upload <block/file?>, and then let the hub do whatever it wants with the info, i e connect to the super-database of all good users, generate stats for their fancy homepage, ignore it...what info would the hub need?

FYI, I'll never add something in the ways of DC++ reporting to an external entity...the system is hub based for a good reason, so transfer stats should imho be kept within hubs/hub networks...if a hub owner then wants something else, (s)he can implement it on the hub side, and no changes have to be made to client...

ender
Posts: 224
Joined: 2003-01-03 17:47

Post by ender » 2003-04-11 09:54

IMO, it would be better for DC++ to report it's downloads - if uploads were reported, everybody could fake, but it's much harder to do so with downloads. As for sending a command to the hub, it's OK IMO, as hubs should ignore unknown commands (if they don't, it's bad design), and downstream bandwidth usually isn't an issue for a hub...

mo
Forum Moderator
Posts: 81
Joined: 2003-02-06 11:20
Location: Ohio
Contact:

Post by mo » 2003-04-11 10:22

I agree that the information should remain between the hub and client.
I also agree with ender about sending downloads, not uploads.

Only catch is, what happens when the downloader has left the hub...
The uploader gets no points for all his work...

I would suggest that the information sent would be the following
$StatUpdate FileSize ULUser ULFile
where...
ULUser = CRC32(UploaderUserName+UploaderUserDesc)
ULFile = CRC32(FileName)

The hub should try to ensure the following
1) ULUser is not the person sending the $StatUpdate
2) DLUser is not sending the info for someone at the same ip

GargoyleMT
DC++ Contributor
Posts: 3212
Joined: 2003-01-07 21:46
Location: .pa.us

Post by GargoyleMT » 2003-04-11 11:02

I think that a large part of the discussion talked about whether the ratings system would be better as part of the hub or not. I don't think there was much continued debate that it would be good on the hub end after the first couple exchanges about the topic.

Reporting stats is a bit useless without an infrastructure to do something with them, and I don't think we need to force more potential liability onto hubs by letting them see exactly what people have downloaded from others...

This feature, on my own little motivation scale, is below at least:
Upload Queueing (experimenting, since I think it'd be beneficial)
File Hash Support
Multi-Source Support
Generic Meta-Data Support

mo
Forum Moderator
Posts: 81
Joined: 2003-02-06 11:20
Location: Ohio
Contact:

Post by mo » 2003-04-11 11:20

I agree that the hub should not know what is being transfered and that is why I suggested the CRC32 hash of the information.

When clients are requesting the rating of a user, they would simply ask for the rating of the user 178361283.
At no time would the hub actually have any incriminating information,
just a bunch of fairly meaningless numbers.

FYI, the CRC32(filename) is not really neccisary for the system to work, just thought someone might be able to use the information for data cleanup or something.

mo
Forum Moderator
Posts: 81
Joined: 2003-02-06 11:20
Location: Ohio
Contact:

Post by mo » 2003-04-11 11:25

I think the reason arne is bringing this up is because the reporting side of this is the first step and also very easy to implement.

Using the data in some meaningful way is the second step, and it may require other features to be implemented like your Upload Queueing.

arnetheduck
The Creator Himself
Posts: 296
Joined: 2003-01-02 17:15

Post by arnetheduck » 2003-04-14 06:20

Downloads, yes...that's probably what I thought but didn't write...in any case, mo strikes a point, it's no work to add...what the hubs do with it, I don't care, but at least they can use it...detecting fake sharers is the most probable campus...
Users that leave the system are obviously a problem, but they always are and shouldn't be many, so in the end, who cares...this is a heurestic system, not an absolute implementation...we're dealing with statistics, so 100% accuracy is not an objective...
What needs to be sent is a file/block-size and the user involved...I don't see any point in sending anything else (filename)...crc32 of the nick...well...why bother? the nicklist is always available for everyone to calc crc32:s so?...nick directly is easier...if the hub then wants to make a nice little database that's saved longer than a session, then it's up to the hub to make sure the info is saved properly depersonalized...

sarf
Posts: 382
Joined: 2003-01-24 05:43
Location: Sweden
Contact:

Some points that was discussed earlier

Post by sarf » 2003-04-15 13:59

Nice seeing that reporting uploads/downloads has been taken up here. Let me just reiterate a few points of what volkris, I and others discussed :
  • there is no real reason to force the client to participate since this should be a voluntary on the part of the client... the person controlling the client should want to report stuff (to get a higher rating in that system)
  • a reason to use a special ratings server was that the ratings server would not necessarily be tied in with a hub... since the ratings server could be used by many users whose ratings would then be persistent across several hubs
  • another reason is that giving the raw data to the hub in this manner invites abuse (and suspicion of abuse by the operator of the hub), while reporting uploads to a ratings server could be somewhat more... neutral, should the server be administrated by someone not affiliated with a certain hub
  • the reason to use a seperate ratings server would be the elimination of a need to extend/modify/care about the DC protocol (and DC++ extensions) - a new (very simple) protocol would be used, which would be independent on DC protocol changes
  • another reason are also that it is easier to maintain a seperate codebase with the ratings server application stuff than to make patches for the different hub softwares out there
  • creating something completely new would allow the creators to stamp his/her/their name(s) all over it and take all credit :) - it is also more fun to create new things than fiddle with old stuff that aren't yours to begin with, and being held accountable if something breaks
These reasons we came up with are based in what we would like to have as well as our "vision" (anyone remember Verants "visions"? :) ) of what people would do.

I do not believe people would want to report what they are downloading/uploading to the hub Giving this power to the hub would not benefit the user, thus the user would strive to give inaccurate information (such as not being able to give the information due to the use of an earlier version of DC++).
The rating server, on the other hand, could be "trusted" since it should only be possible to get a rating from it. The rating could conceivably be determined by a number of factors chosen by the client that requested it, but the underlying data would never be exposed.

Hope this can help you. Feel free to comment/add to the points I take up here, and keep in mind that they are but a fragment of the things we discussed at "the other thread".

Sarf
---
Pro'-gram 1) n. A magical spell cast over a computer which transforms user input into error messages. 2) vt. An activity similar to banging one's head against a wall, but with less opportunity for relief.

Locked