Todd Pederzani writes:
> Fredrik Tolf wrote:
> > >Really? I would have thought that it would take to much hub resources
> >to do that. Do you really think that it's feasible?
>
> Well, if it's unfeasible, I'm not sure how eDonkey servers pull it off > with a much higher user count than DC hubs. ;)
> I'm a fan of this, because it directly benefits me: too many users > cannot configure active mode correctly.  An automated method to inform > them they're misconfigured and force them to passive mode is a good > thing.  And it can be armored against protection by the hubs (test only > the IP they connect from, test only once every 5 minutes unless the port > changes, not test if machine load is above xxx, don't test if user pings > drop [saturated upstream], etc.)

Indeed. I would have liked the idea; it's just I was so sure that
connecting would require to much of a hub's resources. However, now
that you inform me that it's a real alternative, I'm all go for
it. Shell we settle on that? (Of course, a warning system can still be
good for other reasons, not least fakesharing)

> If 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.

Oh yes, but that requires original DC semantics - sorry for not making
myself clear on that, but I was planning on having the downloaders
connect (by default) in this protocol. That's why I want to publish
the address in the client description. This way, noone will have to
waste the hub's bandwidth to connect to someone who is in active
mode. No more CTMs unless the other user is in passive mode.

> I 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.

Does it really? Of course, to try very advanced techniques, it might
require OP intervention, but I think lots of things can be tested
automagically, such as connecting to a user, downloading the file
list, comparing the total size of all files in the list against the
indicated share, try to download a few large files at random from the
list to see if they exist, etc. Aren't these already things that many
hubs already implement through scripting?

Fredrik