partitions sometimes occur in a distributed network; when this happens, a node can only communicate to a subset of other nodes in the network and may use a different chain as the main chain; since current spec recommends a confirmation of 6 blocks, and current block generation speed is about 10 min / block, this means it is possible to invalidate a transaction if there is a network partition lasting longer than 1 hour; i was wondering how bitcoin client is implemented so that it know it is communicating with the full network and not suffering such network partition;
There are no network level controls for this, as far as I'm aware, simply because there is no real way to discover every node in the network.
Instead, partitions are likely to not last very long as the mining power will also be distributed between the partitions. This means that for a partition with only 10% of the mining power, it will take rather long to mine six blocks, while the partition with 90% of the power will quickly establish a longer chain.
There are some efforts made to given nodes varied peers. If I'm not mistaken, the BTC DNS seeds will try and return different nodes for each request, so that you don't end up with too many nodes connecting only to each other, and have a more varied peer graph.
Additionally, if there is a minor partition, it is fairly likely the the partition will reconnect soon. At that point, since one partition will almost definitely be longer, it will become the dominant chain again. If both partitions are equal, the next block after the partition will make a dominant chain appear.