[CONCHECK]

[dangvohoanganhvn]

I noticed that you recently registered conCheck to the redirector. Why does conCheck need to do that?

I’ve implemented a streaming application that uses conCheck to check the P2P capability of clients.
P2P capability can be classified as follows:

Type 1: Can establish P2P connections directly without using an introduction server. These clients are usually not behind NAT, or they have no NAT restrictions, and can connect directly through any IP:port like a server.

Type 2: When sending/receiving packets, the client’s public IP:port remains unchanged. Therefore, P2P connections can be established with other clients through an introduction server.

Type 3: When sending/receiving packets, the client’s public IP:port changes depending on the destination.

From my understanding:

Type 1 can establish P2P with any type.

Type 2 can only connect with other Type 2 clients.

Type 3 can only connect with Type 1 clients.

Is my understanding correct, or am I missing something about how conCheck is used?

[zenomt]

I noticed that you recently registered conCheck to the redirector. Why does conCheck need to do that?

the two main reasons i added redirector registration to conncheck are: (1) to be able to load balance multiple instances or have redundant instances; (2) to be able to run an instance behind a NAT (though most likely it couldn't support all of the tests), but at the very least it could report the client's IP address and port. (2) is also why i made some of the tests (and their host requirements) optional.

Is my understanding correct, or am I missing something about how conCheck is used?

you're mostly correct, though the behavior of NATs and firewalls and their impact on end-to-end connectivity is a little more nuanced and annoying. there are more combinations than you have listed.

conncheck lets you mostly do the same kinds of checks as STUN to characterize your NAT/firewall, just driven from the other direction (see RFC 5780). this functionality was discussed in Matthew Kaufman's slides from IETF 77 (see slide 56). the conncheck in this repository is a rewrite of the functionality Matthew described in the original that we ran at Adobe back then (i wrote that one too :) ). note there is an IPv6 RTMFP connectivity checker running today at rtmfp://cc.zenomt.com which you can connect to with tcconn.