In many situations, peers run in hosts of a private networks (see the “Before” part of Figure 4). However, if two or more users that are in the same private network want to play different players, a simple and efficient solution consist in creating a private team using the peer that belong to the public team as a source fo the private splitter (see the “After” part of Figure 4).∗ ∗The reader could think that running another peer inside of the private network the same effect could be achieved. Nonetheless, this is not true because peers know each other by means of a public NAT end-point and most NATs does not allow to communicate private processes using their public end-points. Note that, as IP multicasting is available on the private network, the private team should be configured to take advantage of this fact.
Similarly as it happens with transparent Web proxies, this locality-aware clustering concept could be also used by ISPs in order to minimize inter-ISP traffic. In a nutshell, if a ISP detecs that there is P2PSP traffic between “local” peers and “foreign” peers, the ISP could deploy a private team. This can be configured by filtering the list of peers that the splitter sends to the peers. This filtering should be performed depending on the locality of the IP addresses of the peers.