728x90

Peer-to-Peer Connectivity

The GKSession class allows your application to create and manage an ad-hoc Bluetooth network, as shown in Figure 1. Copies of your application running on multiple devices can discover each other and exchange information, providing a simple and powerful way to create multiplayer games on the iPhone. Further, sessions offer all applications an exciting new way to allow users to collaborate with each other.

Figure 1  Bluetooth networking

Bluetooth Connection

Bluetooth networking is not supported on the original iPhone or the first-generation iPod Touch. It is also not supported in Simulator.

When you develop a peer-to-peer application, you can either implement your own user interface to show other users discovered by the session or you can use a GKPeerPickerController object to present a standard user interface to configure a session between two iPhones.

Once the network between the devices is established, the GKSession class does not dictate format for the data transmitted over it. You are free to design data formats that are optimal for your application.

Note: This guide discusses the infrastructure provided by the peer-to-peer connectivity classes. It does not cover the design and implementation of networked games or applications.

Sessions

Sessions are created, they discover each other, and they are connected into a network. Your application uses the connected session to transmit data to other iPhones. Your application provides a delegate to handle connection requests and a data handler to receive data directed to your application from another iPhone.

Peers

iPhones connected to the ad-hoc network are known as peers. A peer is synonymous with a session running inside your application. Each session creates a unique peer identification string, or peerID, used to identify them to other users on the network. Interactions with other peers on the network are done through their peer ID. For example, if your application knows the peer ID of another peer, it can retrieve a user-readable name for that peer by calling the session’s displayNameForPeer: method, as shown in Figure 2

Figure 2  Peer IDs are used to interact with other peers

Peer IDs are used to communicate with other peers.

Other peers on the network can appear in a variety of states relative to the local session. Peers can appear or disappear from the network, be connected to the session, or disconnect from the session. Your application implements the delegate’s session:peer:didChangeState: method to be notified when peers change their state.

Discovering Other Peers

Every session implements its own specific type of service. This might be a specific game or a feature like swapping business cards. You are responsible for determining the needs of your service type and the data it needs to exchange between peers.

Sessions discover other peers on the network based on a session mode which is set when the session is initialized. Your application can configure the session to be a server, which advertises a service type on the network; a client, which searches for advertising servers; or a peer, which advertises like a server and searches like a client simultaneously. Figure 3 illustrates the session mode.

Servers advertise their service type with a session identification string, or sessionID. Clients find only servers with a matching session ID.

Figure 3  Servers, clients, and peers

Servers, Clients and Peers

The session ID is the short name of a registered Bonjour service. For more information on Bonjour services, see Bonjour Networking. If you do not specify a session ID when creating a session, the session generates one using the application’s bundle identifier.

To establish a connection, at least one iPhone must advertise as a server and another must search for it. Your application provides code for both modes. Peers, which advertise and search simultaneously, are the most flexible way to implement this. However, because they both advertise and search, it takes longer for other devices to be detected by the session.

Implementing a Server

A copy of your application acting as a server initializes the session by calling initWithSessionID:displayName:sessionMode: with a session mode of either GKSessionModeServer or GKSessionModePeer. After the application configures the session, it advertises the service by setting the session’s isAvailable property to YES.

Servers are notified when a client requests a connection. When the client sends a connection request, the session:didReceiveConnectionRequestFromPeer: method on the delegate is called. A typical behavior of the delegate should be to use the peerID string to retrieve a user-readable name by calling displayNameForPeer:. It can then present an interface that lets users decide whether to accept the connection.

The delegate accepts the request by calling the session’s acceptConnectionFromPeer:error: or rejects it by calling denyConnectionFromPeer:.

When the connection is successfully created, the delegate’s session:peer:didChangeState: method is called to inform the delegate that a new peer is connected.

Connecting to a Service

A copy of your application acting as a client initializes the session by calling initWithSessionID:displayName:sessionMode: with a session mode of either GKSessionModeClient or GKSessionModePeer. After configuring the session, your application searches the network for advertising servers by setting the session’s isAvailable property to YES. If the session is configured with the GKSessionModePeer session mode it also advertises itself as a server, as described above.

When a client discovers an available server, the delegate’s session:peer:didChangeState: method is called to provide the peerID string of the discovered server. Your application can call displayNameForPeer: to retrieve a user-readable name to display to the user. When the user selects a peer to connect to, your application calls the session’s connectToPeer:withTimeout: method to request the connection.

When the connection is successfully created, the delegate’s session:peer:didChangeState: method is called to inform the application that a new peer is connected.

Exchanging Data

Peers connected to the session can exchange data with other connected peers. Your application sends data to all connected peers by calling the sendDataToAllPeers:withDataMode:error: method or to a subset of the peers by calling the sendData:toPeers:withDataMode:error: method. The data is an arbitrary block of memory encapsulated in an NSData object. Your application can design and use any data formats it wishes for its data. Your application is free to create its own data format. For best performance, it is recommended that the size of the data objects be kept small (under 1000 bytes in length). Larger messages (up to 95 kilobytes) may need to be split into smaller chunks and reassembled at the destination, incurring additional latency and overhead.

You can choose to send data reliably, where the session retransmits data that fails to reach its destination, or unreliably, where it sends it only once. Unreliable messages are appropriate when the data must arrive in real time to be useful to other peers, and where sending an updated packet is more important than resending stale data (for example, dead reckoning information).

Reliable messages are received by participants in the order they were sent by the sender.

To receive data sent by other peers, your application implements the receiveData:fromPeer:inSession:context: method on an object. Your application provides this object to the session by calling the setDataReceiveHandler:withContext: method. When data is received from connected peers, the data handler is called on your application’s main thread.

Important: All data received from other peers should be treated as untrusted data. Be sure to validate the data you receive from other peers and write your code carefully to avoid security vulnerabilities. See the Secure Coding Guide for more information.

Disconnecting Peers

When your application is ready to end a session, it should call the disconnectFromAllPeers method.

Your application can call the disconnectPeerFromAllPeers: method to disconnect a particular peer from the connection.

Networks are inherently unreliable. If a peer is non responsive for a period of time, it is automatically disconnected from the session. Your application can modify the disconnectTimeout property to control how long the session waits for another peer before disconnecting it.

Your application can detect when another peer disconnects inside the delegate’s session:peer:didChangeState: method.

Cleaning Up

When your application is ready to dispose of the session, your application should disconnect from other peers, set the isAvailable flag to NO, remove the data handler and delegate, and then release the session.

The Peer Picker

While you may choose to implement your own user interface using the GKSession's delegate, Game Kit offers a standard user interface to the discovery and connection process. A GKPeerPickerController object presents the user interface and responds to the user’s actions, resulting in a fully configured GKSession that connects the two peers. Figure 4 illustrates how the peer picker works..

Figure 4  The peer picker creates a session connecting two peers on the network

Peer Picker

Configuring the Peer Picker Controller

Your application provides a delegate that the controller calls as the user interacts with the peer picker.

The peer picker controller’s setConnectionTypesMask: property is used to configure the list of available connection methods the application offers to the user. In iPhone OS 3.0, the peer picker can select between local Bluetooth networking and Internet networking. When your application sets the mask to include more than one form of network, the peer picker controller displays an additional dialog to allow users to choose which network they want to use. When a user picks a network, the controller calls the delegate’s peerPickerController:didSelectConnectionType: method.

Important: In iPhone OS 3.0, the peer picker does not configure Internet connections. If your application provides Internet connections, when the user selects an Internet connection, your application must dismiss the peer picker and present its own user interface to configure the Internet connection.

If your application wants to customize the session created by the peer picker, it can implement the delegate’s peerPickerController:sessionForConnectionType: method. If your application does not implement this method, the peer picker creates a default session for your application.

Displaying the Peer Picker

When your application has configured the peer picker controller, it shows the user interface by calling the controller’s show method. If the user connects to another peer, the delegate’s peerPickerController:didConnectPeer:toSession: method is called. Your application should take ownership of the session and call the controller’s dismiss method to hide the dialog.

If the user cancels the connection attempt, the delegate’s peerPickerControllerDidCancel: method is called.

728x90

'BlueTooth > 기본기' 카테고리의 다른 글

Bluetooth Packet Type  (0) 2013.11.06
quoted-printable decoder  (0) 2013.06.03
synergy MessageSendLater  (0) 2011.04.19
bluelab stereo 2009.R2 Inquiry시 iPhone이 검색되면 panic  (0) 2011.03.30
Apple 개발문서  (4) 2010.03.15
iphone간 bluetooth 연결 sample  (1) 2010.03.04
아이폰 블루투스 프로그래밍  (3) 2010.03.03
bluetooth keypad  (0) 2010.02.10
Bluetooth 2.0 under에서 Pincode없이 연결  (0) 2009.12.28
bluetooth hfp 정리  (0) 2009.07.24

+ Recent posts