It is interesting to watch the development of the file-sharing network, but it is even more interesting to participate in it.
Today, by installing and running a modern hub, the newly-made administrator gets access to almost all the developments and experience accumulated in this area by his predecessors. It has a system ready for expansion and customization, including with the help of numerous scripts.
Π‘ hubs otherwise. The structure of this protocol suggests extensibility. Do you want a new feature? Well - offer, promote, implement, implement, use.
As a result, you can, of course, get a ready-made hub out of the box, but just launching and forgetting about it will not be good. Extensibility in a historical context implies, among other things, the presence of a different number of different functions of client and server software, depending on the version. And what will work without problems for one user may be incompatible with the client of another, and this must be taken into account.
This is what happened with IPv6. The old man NMDC does not know how to do it in principle, but ADC itself is ready for it. However, not all so simple.
Quite a bit of theory
An "active" user can accept incoming connections. Actually, the connection request coming from it is actually invitation.
A "passive" user can generally only use outgoing requests. Through the hub asks active user to send an invitation - and the connection is obtained.
And yes, this mechanism does not depend on the version of the IP protocol used.
Swan, cancer and pike
Let's talk about client software.
IPv6 support in is experimental. There are no separate settings for it, and it was all the more surprising for me to see different modes of operation for different versions of IP, and passive just for the sixth, but this is inaccurate.
It was not possible to get an active mode during manual configuration even when explicitly using an IP domain with an AAAA record as a WAN, but in automatic mode using UPnP everything worked as it should.
also has support for IPv6 connections, and it is implemented completely separately from IPv4. Moreover, this client modifies user tags in such a way as to display operating modes for both IP protocols at the same time. The hubs themselves do not (yet) know how to do this, which is a pity.
I must make a reservation right away: AirDC ++ does this alone and for itself. In what follows, for convenience, I will use combinations like AP or AA as an indication of the active or passive modes of operation for IPv4 and IPv6, respectively, and not their display in the tag of a real client on a real hub. It is important.
In our experiment, we will use FlylinkDC++ as a client not at all familiar with IPv6. It should also be noted that support for him at the time of this writing was not implemented anywhere.
Home
First of all, we will consider obviously impossible connections between users of different versions of the IP protocol. For the test will be used with A and AAAA resource records for the domain name acting as its address.
Note that if you (actually) try to access a user with an IP address of the sixth version, an error is displayed here.
Hub: [Outgoing][IPv4:412] DRCM AACX AACU ADCS/0.10 337151563
Hub: [Incoming][IPv4:412] DCTM AACU AACX ADCS/0.10 1988 337151563
Hub: [Outgoing][IPv4:412] DSTA AACX AACU 240 IPsunknownTranslated into human, it sounds like
P4: - Can I hook you up?
A6: β Cling!
P4: β Life pain 0_0
A short dictionary, if anything, .
And if vice versa, and the connection initiates A4, then no error is displayed, and the connection simply hangs.
Hub: [Outgoing][IPv4:412] DCTM AACX AACU ADCS/0.10 1993 3871342713Be, not seem to be
What is important is the connection mode displayed on the hub.
Clients without IPv6 support will have to see users connected through it as clearly passive, simply because for them the hub does not fill I4 or I6 field, respectively.
FlylinkDC++ vs. IPv6
In fact, the situation is simpler and more complex at the same time.
AirDC++ vs. IPv6
Easier because IPv6 takes precedence over IPv4, and that's understandable. It is through it (although an override is available with the help of the corresponding option) that a connection to the hub will be established, and its active client will offer a passive one for connection.
Itβs more difficult, because if there are users with IPv6 support on the hub, but they are connected strictly through an IPv4 address, then ...
... then you can connect with them (at random) without having IPv4 at all.
Note that the remote client has designated itself as an asset, but is treated as a liability. Why?
There it in the swing
Now let's try to connect with each other clients with different, but common in terms of IPv4 sets of support for the IP protocol.
Yes, it's a pity that passive users have to smoke on the sidelines. But this cannot be helped, since their visible IP address does not really matter - that's why they are liabilities.
Ba! Active client sends ?.. It would be logical to expect a βhangingβ connection, but no, it is obtained on the conditions A4.
Why is that? We contact the developer and get the answer:
isn't good if the other user doesn't support IPv6
And you can't argue! But this requires internal, hub-independent logic (see code ΠΈ ). Liabilities still cannot be helped, because
active mode =
Attempts to connect between clients with common sets of IP protocol support in terms of IPv6 look like this. Remind me to achieve PA for DC++ I failed.
And again a surprise. It turns out that the passive mode for IPv6, which demonstrates DC ++, is either an intentional fake or a bug.
What's next?
Currently, there are exactly two ways to solve all possible problems of connecting users in different modes and with different sets of IP protocol support.
The first is to mute IPv6 altogether or, conversely, create a hub to work only through it.
The second one is this , which is just approaching the testing stage.
Well, being too lazy to configure the active mode to work in DC, remember:
Whoever has, to him will be given, and whoever does not have, what he thinks to have will be taken away from him. Lx 8:18
Source: habr.com