8.6. Peer-to-Peer Networking

The previous examples have been built on the client–server architecture: the roles of the client and the server have been distinct. The client–server architecture makes sense if the service requires a common 'shared memory' or some other common resource, which is maintained by the server and accessed by the clients. In the voting example, the server maintained the status of voting, which can be seen as an instance of 'shared memory'.

However, think of an instant messaging service or a game of chess between two players. In the former case, the service has no shared state or memory; individual messages are passed back and forth. In the latter case, the state of the shared chess board is easily maintained by both the clients (players) separately. These programs could work without a central server. The communication takes place only between individual phones in a peer-to-peer manner (Figure 8.6).

Figure 8-6. Peer-to-peer networking

The issues related to server-side sockets on the phone also apply to peer-to-peer networking, making universal real peer-to-peer services difficult to implement. By real peer-to-peer networking we mean that the phones are able to communicate directly with each other, without help from any central server. The Bluetooth chat example in Section 7.3 was a real peer-to-peer application in this sense.

Many WiFi-enabled phones support ...

Get Mobile Python: Rapid Prototyping of Applications on the Mobile Platform now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.