Sign In
Register
Just a thought about LowID and KAD!
In many cases the broadband routers on the market are full-cone NATs for UDP packets to make them work better with VoIP protocols. This means that KAD should work perfectly on them, just that you can't set up TCP sessions against these clients. But one idea would be to make the LowID clients that are behind full-cone NATs to put them selves as the buddy client. The only thing we need to do is to detect the NAT type and our external port number to make this work.
/netfinity
Page 1 of 1
KAD firewalled on Full Cone NATs splitted
#1
- Master of WARP
-
- Group: Members
- Posts: 1658
- Joined: 23-April 04
Posted 05 October 2007 - 09:31 PM
eMule v0.50a [NetF WARP v0.3a]
- Compiled for 32 and 64 bit Windows versions
- Optimized for fast (100Mbit/s) Internet connections
- Faster file completion via Dynamic Block Requests and dropping of stalling sources
- Faster searching via KAD with equal or reduced overhead
- Less GUI lockups through multi-threaded disk IO operations
- VIP "Payback" queue
- Fakealyzer (helps you chosing the right files)
- Quality Of Service to keep eMule from disturbing VoIP and other important applications (Vista/7/8 only!)
- Compiled for 32 and 64 bit Windows versions
- Optimized for fast (100Mbit/s) Internet connections
- Faster file completion via Dynamic Block Requests and dropping of stalling sources
- Faster searching via KAD with equal or reduced overhead
- Less GUI lockups through multi-threaded disk IO operations
- VIP "Payback" queue
- Fakealyzer (helps you chosing the right files)
- Quality Of Service to keep eMule from disturbing VoIP and other important applications (Vista/7/8 only!)
Back to top
Reply
#2
- Neo Dev
-
- Group: Members
- Posts: 1469
- Joined: 23-April 04
Posted 06 October 2007 - 07:51 AM
As far as I see there is actually nothing in the KAD code that would prevent this and it seams that kad 2 does not longer send thePrefs.GetUDPPort() any ware so always the seen port is used and the KAD already works on full cone NATs, or do I oversee something?
Only the Full cone LowID buddy's would need to be implemented, what shouldn't be so hard.
btw: My NatT code is designed in a way that if the remote client is a FullCone NAT one we can connect to him without a callback (excepted the very first connection where we have to get his extern UDP port)
David
Only the Full cone LowID buddy's would need to be implemented, what shouldn't be so hard.
btw: My NatT code is designed in a way that if the remote client is a FullCone NAT one we can connect to him without a callback (excepted the very first connection where we have to get his extern UDP port)
David
NeoLoader is a new file sharing client, supporting ed2k/eMule, Bittorent and one click hosters,
it is the first client to be able to download form multiple networks the same file.
NL provides the first fully decentralized scalable torrent and DDL keyword search,
it implements an own novel anonymous file sharing network, providing anonymity and deniability to its users,
as well as many other new features.
It is written in C++ with Qt and is available for Windows, Linux and MacOS.
it is the first client to be able to download form multiple networks the same file.
NL provides the first fully decentralized scalable torrent and DDL keyword search,
it implements an own novel anonymous file sharing network, providing anonymity and deniability to its users,
as well as many other new features.
It is written in C++ with Qt and is available for Windows, Linux and MacOS.
#3
- Last eMule
-
- Group: Yes
- Posts: 3667
- Joined: 27-June 03
Posted 06 October 2007 - 09:55 AM
Yes this is an intresting point which should be considered, the only problem will be a test for this situation, because there would have to be an incoming UDP packet from a client which we didn't sent any UDP packet yet. But this is only a question of the implementation of course, if there are really many full cone NATs out there then this would help them a lot to use kad.
#4
- Last eMule
-
- Group: Yes
- Posts: 3667
- Joined: 27-June 03
Posted 16 October 2007 - 10:55 PM
Now that there are some numbers, its possible to do a first quick evaluation on this suggestion: Unfortunatly the number of users of have a Full Cone NATs is a lot smaller than hoped and lies between 10 to 20 percent (the rest beeing restricted cone NATs). So this won't make a big impact on the lowid numbers unfortunatly. However, given that those numbers are still significant and that we will have to rework the whole KAD firewallcheck thing anyway (basically splitting it in seperate UDP and TCP stats, making it PAT aware and restricted cone aware) and that there is basically no drawback its probably worth a closer look nevertheless.
Page 1 of 1
