TECHNICAL ROAD TO 3.2

[Logan007]

• UPnP support UPnP / NAT-PMP support #147 Hoping to get into upnp #817 (assigned: Fengdaolong)
• support for --pre-up, --post-up, --pre-down, --post-down CLI options to run scripts Would like to have wireguard-like feature in N2N #694 support multi address per node and same address for multi node #743 (assigned: -)
• support for --pre-add-new-peer and --post-flush-old-peer CLI options to run scripts (assigned: -)
• MAC-based supernode selection Is there any way to make the supernodes in active/standby mode but not in load-balance mode? #860 (assigned: Logan)
• transmission-critical code path optimization (assigned: -)
• add IPv6 support (assigned: Logan)

Optional:

• multi-link support (assigned: -)
• prepare inter-supernode communication (assigned: -)

This is about what technical features to include / change for a future n2n 3.2 release. This post will regularly be updated to reflect current changes.

The list above is absolutely not carved in stone. Please share your thoughts for discussion and do not hesitate to propose any of your ideas!

If you want to contribute to some of the listed features such as upnp support, or to a not-yet-listed feature... just let us know!

[hamishcoleman]

In addition to the four hook scripts above, I have thought that it would be nice to have pre-add-new-peer and post-flush-old-peer script hooks.

The use case I see here is for the case where the default route is via the n2n device. Any new peer (or supernode) that gets added would need to have a host route added to access it, so these script hooks could let that happen.

[Logan007]

I have thought that it would be nice to have pre-add-new-peer and post-flush-old-peer script hooks.

We could try to make it happen. I will add it to the list as additional item because implementation might differ from the others (parameters, called from deep inside the main loop).

@hamishcoleman , I would be glad if we found an opportunity to talk or chat about future features sometime soon. Are you aware of ntop's Discord server?

[hamishcoleman]

I am not often on discord, so I had not previously looked - however, I joined the libera.chat irc channel as soon as it was created (and basically nobody else joined it :-S)

[Logan007]

You can find the Discord server linked to on ntop.org 's community page. That would be the official forum including a helpful bot channel to keep an eye on repository's changes.

[fengdaolong]

Discord often blocks access for some reasons, so I created an IRC channel #763 , and I am willing to give the management authority to the official.

[fengdaolong]

Some people claim that the transmission speed of n2n is not as good as other similar software. I think the next version can consider increasing the transmission rate of n2n.

[Logan007]

transmission speed of n2n

I will put it as "transmission-critical code path optimization".

[hamishcoleman]

It also implies that we need some clear and reproducible benchmark numbers that we can start tracking

[Logan007]

mmmm... a reference setup.

[tlsalex]

thanks for keeping this item in list -- support for --pre-up, --post-up, --pre-down, --post-down

[fengdaolong]

I think that some additional functions can be moved into a separate thread, including: port mapping, domain name resolution, MgmtSocket, update supernode reg, etc., to minimize the burden on the main thread, maybe it helps to increase the transmission rate.

the additional thread does not need to be opened too much, one is sufficient, what do you think of this proposal?

[Logan007]

moved into a separate thread

👍

This is exactly the lead idea behind the ongoing threadification over at f96b08c.

one is sufficient, what do you think of this proposal?

Not sure about one though.

[fengdaolong]

Looking back at the issues we have discussed, up to now, most of the functions have been completed, but there are still many areas that need to be improved.
regarding the introduction of KAD, this is a big project, is it in the 3.2 version plan?

[Logan007]

is it in the 3.2 version plan?

We want to keep the protocol compatible in the 3.x series. A higher degree of p2p-ification will not work without notable changes to protocol. Hence, 4.0 is the more likely to be the appropriate target for it.

So, there is a lot time left for discussion. And we will need it because it indeed is a big change and has not been discussed in-depth yet. It does not necessarily need to end up in KAT whose native routing is bad for network performance which would require to add separate routing. Not only doubling complexity, KAT would only serve for peer look-up then. Would it be worth the effort?

But basically yes, the 4.x series shall move more towards p2p plus merge the supernode and edge functions into one executable.

[lucktu]

When to support ipv6？ #465

[lucktu]

Increase the efficiency of p2p. #774 & #784

[Tim-Paik]

I think it would be very good to add IPv4+IPv6 support, because IPv6 basically has no NAT, which can increase the success rate of hole punching a lot

[Logan007]

I actually am doing some trials to support IPv6. It requires a lot of adaptions to the code and data structures. Let's see for far we get. So I will add IPv6 support as optional item.

From what I have seen so far, IPv6 does not necessarily increase the p2p-success rate because home routers's firewall still watch connections and try to make sure that only remote addresses/ports seen in outgoing packets are eligible for incoming ones. The firewall plays not an unimportant role here, no matter if v4 or v6. Don't get me wrong, I do no want to turn down IPv6 support, I even think it is time to add it soon for technological reasons anyway. It might just not help as much as one may expect.

[introspection3]

I actually am doing some trials to support IPv6. It requires a lot of adaptions to the code and data structures. Let's see for far we get. So I will add IPv6 support as optional item.

From what I have seen so far, IPv6 does not necessarily increase the p2p-success rate because home routers's firewall still watch connections and try to make sure that only remote addresses/ports seen in outgoing packets are eligible for incoming ones. The firewall plays not an unimportant role here, no matter if v4 or v6. Don't get me wrong, I do no want to turn down IPv6 support, I even think it is time to add it soon for technological reasons anyway. It might just not help as much as one may expect.

What new features will you add to ipv6，sir?

[marek22k]

+1 for support for --pre-up, --post-up, --pre-down, --post-down and IPv6!