Ämne:Re: [dcdev] Re: Thoughts about Fredrik's draft
Till:Direct Connect developers
Really? I would have thought that it would take to much hub resourcesWell, if it's unfeasible, I'm not sure how eDonkey servers pull it off with a much higher user count than DC hubs. ;)
to do that. Do you really think that it's feasible?
If I'm not incorrect, none of the things it will detect are very proneIf a user is behind a router, hasn't entered his external IP into the settings, and goes to download a list from someone - they will send a CTM with their private network IP. The remote user, of course, cannot connect to them using that. After a short while, DC++ will stop waiting for an incoming connection and display "Connection timeout." For all intents and purposes, the misconfigured user "cannot connect" to other user. This probably will only happen with users new to the DC network, which means it will happen on a regularly annoying basis.
to misconfiguration. Connecting to a user won't be affected by many
(or any?) factors that I can think of. Likewise, fakeshared files
don't have any apparent misconfiguration factors that I can think of
In any case, though, to avoid that users would increase a hubs load byI think the idea of an automagical warning system is novel... but it's really quite unworkable - ultimately, it requires OP intervention, and their judgment about whether or not it's a real problem. Essentially, you're making a new feature that's the same as PMing OPs. Though it might be simpler, isn't educating users that they should report odd behavior by telling OPs a much better long-term solution? How would any automated system establish the two-way communication you need to figure out what is really going on?
misusing it, I was thinking that, if the hub investigates a warning
and detects it to be bogus, it could ignore further warnings from that
same client for five minutes or so.