I4/I6 should be broadcasted regardless of TCP4/TCP6
May 9, 2011 3 Comments
In ADC, it’s possible for clients to announce from which IP they’re connecting. This IP is later usually used to identify what address to connect to if they accept incoming TCP connections. That is, when you want to connect to someone, you announce ‘I4’ (for IPv4; I6 for IPv6) and send a “connect to me” message, or CTM. You also announce TCP4 or TCP6 in the feature field for others.
In ADC (in NMDC as well, really), there are two types of users; those who accept incoming TCP connections and those that do not. The former is usually called ‘active’ and the latter ‘passive’. Active users can connect to other active users. Active users can connect to passive users. Passive users can connect to active users (by a ‘reverse’ CTM message). Passive users can’t connect to other passive users (I’m going to purposefully ignore NAT traversal since it allows passive to passive connections, but it isn’t useful in this discussion).
The reverse CTM for passive to active connections work by a simple mechanism. The passive user says to the active user “RCM”, reverse connect to me. The active user will then proceed to connect to the passive user, and the downloading will commense.
Active clients are basically required to signal their address in the I4/I6 field (that is simply the nature of the field), whereas passive users are not required (but keep reading).
So far so good, nothing bad has happened.
Now, imagine the case where an active user will want to connect to another active user. They both signal I4 (I’ll use it for simplicity sakes, but it applies to I6 as well). The downloader signal address 1.1.1.1, the uploader signals 2.2.2.2. The downloader send to the uploader “connect to me”. The uploader connects through 2.2.2.2.2 to 1.1.1.1, and the communication continues. Everything’s all right for now.
Imagine instead that the downloader is a passive user. The passive user will say to the active user ‘send a connect to me so I can connect to you’. The active user will say ‘connect to 1.1.1.1’, which the passive user connects to. However, the connection can come from anywhere, and not necessarily from the IP the passive user connected to the hub with! That is because the active user does not have any knowledge from which IP the passive user should connect from.
(Now, obviously, there will be a token sent which the passive user will need to verify, but the problem of connection-point do not go away.)
So solve the problem, passive clients should publish I4/I6 regardless of whether they support TCP4/TCP6 or not. If you look at the specification, TCP4/TCP6 require I4/I6 but not the other way around, so this change (i.e. ‘everyone should send ‘I4/I6’) should not have any effect on existing implementations.
Do note that the hub can of course send I4/I6, regardless of whether the client sends it or not.
Don’t forget that you can make topic suggestions for blog posts in our “Blog Topic Suggestion Box!”
Direct Connect: Just These Guys, Ya Know? 
So what benefit do you get from knowing IP address over token?
Token if choosing long enough is unique.
Whilst multiple users may connect from the same IP address to a hub.
Even a user may be in multiple hubs present with same CID+IP but different share. Knowing the IP does just not help in such cases. The token is the only thing that will distinguish a user for you.
Someone else raised the issue that ISPs may charge differently depending on from which network someone is using. That means that if a user connects through 1.1.1.1, they’ll get charged 1 money unit. If someone connects through 2.2.2.2, they’re charged with 2 money units. That means that users have a vested interest in knowing from where a client connect from. I.e., they may filter in their clients whether they want to accept incoming traffic from 2.2.2.2. As such, they don’t want to spend traffic (small amount, but still) figuring out the token.
But yes, I completely agree otherwise with the use of the token.
(Obviously clients will need to add such protection, as described above, both for active and passive connections.)
NAT traversal does have a place in this discussion since it requires hubs to always broadcast IP addresses of connected users.