-
Notifications
You must be signed in to change notification settings - Fork 1
[기술 공유] MultiPeerConnectivity
발표자 | 정석영 |
---|
nearby devices가 제공하는 서비스 검색을 지원하고, 데이터 전송을 하게 해주는 framework이다.
이때, 데이터 전송은 3가지 방식으로 제공된다.
- massage-based data
- streaming data
- resources(file..)
iOS의 경우 다음과 같은 것을 사용하여 검색한다.
- infrastructure Wi-Fi
- peer-to-peer Wi-Fi
- Bluetooth
MacOS에선 다음과 같은 방식을 제공한다.
- infrastructure Wi-Fi
- peer-to-peer Wi-Fi
- Ethernet
infrastructure vs. peer-to-peer
둘 다 LAN의 모두의 일종으로 infrastructure은 AP(중계기)를 거치는 LAN이고,
peer-to-peer는 중계기를 거치지 않는 LAN이다.
MultiPeer Connectivity는 크게 다음과 같은 객체가 존재한다.
- Connected된 Peer Device간의 communication을 지원한다.
-
connectedPeers
를 통해 연결된 Peer의 MCPeerID 객체를 저장하고 있다.
- 주변 peer에게 session에 참여할 의향이 있음을 알린다.
- Advertiser객체는 다른 Peer에게 정보를 제공한다.
ex)MCPeerID
,discoveryInfo
###MCAdvertiserAssistant
- Advertiser객체와 동일한 기능을 제공하지만, 초대를 수락할 수 있는 표준 UI를 제공한다.
###MCNearbyServiceBrowser
- 주변 device를 검색하는 기능을 제공한다.
###MCBrowserViewController
- 기능은 browser와 같지만, 표준 UI를 제공한다.
###MCPeerID
- 유니크한 Identifier이다.
-
우선,
MCNearByServiceAdvertiser
객체 혹은MCAdvertiserAssistant
객체로 주변 Peer에게 참여할 의향이 있음을 알린다.⇒ 이때, 이니셜라이져 단계에서, 주변 Peer가 Browsing했을 때, 알릴 추가 정보인
discoveryInfo
를 설정할 수 있다. -
MCNearbyServiceBrowser
혹은MCBrowserViewController
객체를 통해 주변 Peer를 검색한다. (정확히는 Advertising된 객체) -
검색된 유저는 delegate
browser(_:foundPeer:withDiscoveryInfo:)
메서드로 오게 된다.⇒ 반면 neerby peer가 사라질 경우,
browser(_:lostPeer:)
로 오게 된다. -
이후, Browsing객체를 통해
invitePeer(_:to:withContext:timeout:)
메서드를 통해 유저를 session 초대하게 된다.⇒ timeout은 양수로만 입력해야 하며, 음수 혹은 0의 경우 30초로 세팅된다.
-
이러한 초대는 Advertising객체의 delegate의
advertiser(_:didReceiveInvitationFromPeer:withContext:invitationHandler:)
로 오게 된다.
💡
invitationHandler는 다음과 같다.
`invitationHandler: @escaping (Bool, MCSession?) -> Void`
이때, Bool을 통해 참여의사를 밝히고, 연결할 session(자기 자신의 session)을 전달한다.
만약, 수락을 받게 되면, browser는 advertiser와 connection을 맺고 session단계를 시작한다.
framework는 delegate를 통해 session에 join하고 떠난 것을 알리게 된다.
만약, 앱이 background 상태에 접어들면, framework는 advertising과 browsing을 중단하고, 연결된 session과 disconnect한다.
foreground상태에 접어들면, framework는 browsing과 advertising을 재게하지만, closed session에 대해 재연결을 해주어야 한다.
우선, 위의 phase를 간략하게 정리해보면 다음과 같다.
- advertiser를 통해 주변 peer에게 알린다.
- browser를 통해 advertising된 peer를 검색한다.
- browser는 advertising된 peer에게 초대를 보내게 된다.
- advertiser는 browser로 부터 온 초대를 참여 여부와 자신의 session을 전달한다.
크게 유저의 state정보는 2가지 객체를 통해 감지하게 된다.
- browser
- session
browser에는 다음과 같은 이벤트가 감지된다.
- found
- lost
found는 말그대로 advertising된 유저를 찾게 되면 오는 이벤트이다.
해당 이벤트는 browser객체의 delegate인 browser(_:foundPeer:withDiscoveryInfo:)
로 오게 된다.
lost는 advertising된 유저를 잃게 되면 발생되는 이벤트이다.
해당 이벤트는 browser delegate의 browser(_:lostPeer:)
메소드로 오게 된다.
이 이벤트는 유저가 background상태에 접어들거나, connection을 더이상 맺을 수 없을 때 호출된다.
session delegate인 session(_:peer:didChange:)
로 전달되는 유저 상태 이벤트는 크게 3가지가 존재한다.
- notConnected
- connected
- connecting
말그대로 session 연결이 완료된 상태이다.
session이 형성되고 있는 시점에 호출
더 이상 session을 통해 데이터를 전달할 수 없는 상태이다.
초대를 거절하거나, 상대 peer가 lost상태가 되어 더 이상 보낼 수 없는 상태이다.