what i understood from the docs that the point of TCS should be that tracker would be able to do efficient clustering of peers into teams.
Let's say we're saying that tracker will assign each peer into a separate team. Let's say P1 is such a peer. when a new peer P2 which belongs to same private network as that of P1 comes along tracker will instruct P2 to cluster with P1. That's what you're proposing.
But, the problem is if all of the peers are of different private networks. Then total number of clusters (or teams) will be equal to number of peers. It will be too much load on the source to feed these number of teams. And, its definitely not a efficient clustering mechanism from a tracker point of view.
The kind of algorithm will kind of do the following.
When a peer contacts with tracker, it will do the following.
for each team in its team list, it will calculate the following.
Of course when initial team list is empty, tracker will just assign each peer to a separate team unless they're from same private network. But, it will continue to do so until a max. number of teams(this parameter will be decided based on sources capability to feed simultaneous connections) has been reached. After that, any incoming peer will be added to one of the teams using algorithm above mentioned.
Before: NAT +-+ +------------+ | | +-----+ +--------+ | team - P_i |<----| |---->| P_i |----->| Player | +------------+ | | +-----+ +--------+ +-+ After: NAT +-+ +------------+ | | +-----+ +--------+ | team - P_i |<----| |---->| P_i |----->| Player | +------------+ | | +--+--+ +--------+ +-+ | v +-----+ | S | S = Splitter +-----+ | v +-----+ +--------+ | P_j |----->| Player | +-----+ +--------+
@vicente-gonzalez-ruiz I've been doing some reading about how to go about implementing this into code. And, you're right. We should probably decouple this from core and make platform specific implementation. This will let us use platform specific libraries for socket programming. So, let's start with p2psp-console first.
So, we're going to serve multiple consumers. Should we implement it in a way such that each consumer will have it's own TCP socket? Currently, there's only one UDP serving socket for serving chunks to the peers. But, that's UDP and it's stateless. But, if we're going to take the same approach for TCP it will add to a lot of overheads. (for each new connection we're gonna have SYN/ACKs). Because TCP connections are session-oriented we can just use individual socket per consumer and pass on the chunk to it when it's received. And also we can make this serving individual socket multi-threaded too.
@vicente-gonzalez-ruiz I've some proposals that i would like to share if we're going to implement this.
1) the base class (peer_ims) should implement the following methods.
what do you think of it? Let me know if you want any changes or addition.