Паразитные подключения одного юзера через разные хабы

[Tantrix]

Нужна опция "избегать вторичных соединений с одним и тем же пользователем на разных хабах" при мультискачке. Да и при отдаче, если честно, тоже.

ИМХО, корректно будет работать, только если смотреть на IP юзера.

[RoLex]

Part 1: Add setting to skip queue matching from same user on different hubs, request by Tantrix

/*
	problem:
		we download same file from same user on different hubs
		source user contains same data except hub url and cid
	deeper problem:
		there are many clones with different suffixes in our network
		one solution is to partially compare short nick with long one
	solution:
		compare ip and nick to avoid adding same user more than once
	better solution:
		erase source hub url, cid and possibly nick from user poiter
		in this case we need to store two source objects and check them
*/

[18:04:33] Skipping same source: <1.2.3.4> <[fly]Cool_ABC> <nmdcs://russia.feardc.net>/<dc.cifracom.ru>

Beta: feardc-1322-x64.zip

[Tantrix]

Not effective.

Maybe we should check the source every time it's (re)added, not just during initial download request.

[RoLex]

Is this old queue after client restart? Then you need to manually delete doublette sources one time only. This is because new filter is already bypassed. It's same as you would add doublette sources manually - which is allowed in case user really needs to.

Any new downloads will be affected by new setting.

[Tantrix]

'Is this old queue after client restart?'

No, it is brand new.

https://youtu.be/qkOKuol7pnc

[RoLex]

I got it. You are starting download from search. I tested this too, but the thing is that I don't get search results from same users on different hubs - they are filtered by my proxy, because they are equal eachother 😄

I will add new filter to search frame aswell. Thanks!

[RoLex]

Please test now. ZIP is updated in same location.

[Tantrix]

Uhu. Much better now.

However 1) same user still may be added (and probably never removed) as a source during initial connection attempt (because of 'not ready for download right now' state?).

2. Still nothing to do with the same user using totally different nicknames on different hubs (on the same hub too!).

[RoLex]

Yes, all we can do is compare IP and nick. Maybe I could figure out something with exact share size - one of things that is 99% unique in DC.

Btw, in this version nicks like [fly]Cool_ABC and [fly]Cool_ABC_R123 are correctly filtered.

[Tantrix]

Why not use IP for user identification? Active users all will have their own; passive users not likely will have the same IP and same files simultaneously.

[RoLex]

Mainly because of this. It has become a very popular way of having a hub connection + download tunnel if you have a foreign VPS for example. You are not directly visible to the world, your traffic can be encrypted with correct listener application (remote user <> your server - not always encrypted, your client <> your server - unsecure traffic can be detected and encrypted), you can still achieve active mode, your speed is still great - unlike shared VPN or proxy.

This weekend I will add correct support for clone detection - IP + partial nick / exact share size. This has been in Ledokol for Verlihub for years and works very precise.

[RoLex]

Added share size to detect same source. Updated ZIP in same location.

[Tantrix]

Works just fine in most cases.

Under some circumstances, however, duplicate sources still can be added (most of user's clones ignored, but not all).