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 diﬀerent players, a simple and eﬃcient 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 eﬀect 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 conﬁgured 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 traﬃc. In a nutshell, if a ISP detecs that there is P2PSP traﬃc between “local” peers and “foreign” peers, the ISP could deploy a private team. This can be conﬁgured by ﬁltering the list of peers that the splitter sends to the peers. This ﬁltering should be performed depending on the locality of the IP addresses of the peers.