ProfileDrop - Team-HGD/SniffMEET GitHub Wiki

개요

📝Name Drop 기능처럼 동작하는 우리만의 ProfileDrop 기능 구현

도입

NameDrop 형태의 기능을 메이트 연결 시점에 적용하여 전화번호 대신 프로필 카드를 공유하도록 하고 싶었다.

NameDrop 기능은 따로 제공되는 api가 없기 때문에 비슷하게 동작하도록 직접 구현해보기로 했다.

분석

초기에는 MultipeerConnectivity(MPC) 이용해 주변 사용자를 탐색하고 연결해 데이터를 공유하면 되겠다고 생각했습니다.

하지만 MPC는 와이파이나 블루투스를 이용해 기기를 탐색하고 연결해 데이터를 전송할 수 있는 유용한 기술이지만, 기기 간 거리와 방향에 대한 정보를 세밀하게 다루지는 않아 그저 범위 내 존재 여부만 파악하고 근접 접촉을 판단할 수는 없었습니다.

NameDrop 형태의 동작은 기기 간 위치 파악이 중요하다고 생각해 추가 기능이 필요하다고 결론 내렸고, 팀에서 UWB를 사용해보는건 어떨까 하는 의견이 나와 해당 키워드를 중심으로 찾아보게 되었습니다. 애플에서 지원하는 NearbyInteraction과 NFC 이용한 기술이 적용 가능해보였는데 NFC는 태그를 사용해야 한다는 점이 제약 사항으로 느껴졌습니다. 좀 더 NameDrop과 유사하게 구현할 수 있는 것이라 판단해 NI를 추가 적용하기로 결정했습니다.

NI 기술은 기기 간 거리와 방향을 측정하는 기술이지만, 기기 간 데이터는 공유시켜주지 않습니다. 하지만 NI 세션 연결을 위해서는 DiscoveryToken을 기기끼리 공유해야 하기 때문에 MPC + NI 형태로 저희만의 ProfileDrop 기능을 구현했습니다.

Multipeer Connectivity

Nearby Interaction

사용

MPC + NI 흐름 설계

• 기기들은 각각 NISession과 MPCSession을 독립적으로 시작합니다.
• 각 기기들은 MPCSession을 통해 Advertising / Browsing 작업을 수행합니다.
• 기기가 발견된다면 Invite 하고 세션을 연결합니다.
• NISession은 시작되면 자동으로 기기마다 DiscoveryToken을 생성합니다.
• DiscoveryToken을 기기끼리 교환하기 위해서 MPCSession을 이용합니다.
• DiscoveryToken이 정상적으로 교환되면 NISession으로 연결되고 기기의 거리와 방향을 파악할 수 있습니다.
• 이후, 해당하는 거리와 방향에 있는 기기와 MPCSession을 통해 데이터(프로필 카드)를 교환하게 됩니다.
• 두 피어간에 데이터 교환이 마치게 되면 NI, MPC Session 모두 종료됩니다.

트러블슈팅

초기 구상 플로우와의 차이

기존에는 실제 NameDrop처럼 동작하도록 하기 위해 당연히 백그라운드에서도 기능이 돌아가야 했습니다.

하지만 MultipeerConnectivity는 포그라운드에서만 동작하기 때문에 CoreBluetooth를 추가로 사용해야 백그라운드 지원까지 가능했습니다. 프로젝트 기간적 제한이 있어 우선 MPC 이용한 구현만 진행하기로 했습니다. 그러면서 포그라운드 진입 시점에만 동작하게 되었습니다. 포그라운드 상태에서 계속해서 세션 연결을 시도하고 유지하는 과정에서 리소스 사용이 계속 증가하는 것을 확인하고 버튼을 눌렀을 경우만 ProfileDrop이 실행되도록 플로우를 변경하였습니다.

중복 연결 문제

startAdvertising으로 기기 존재를 광고하고 startBrowsing으로 기기를 탐색해서 invite를 보내는 과정에서, 양쪽 기기 모두 advertising, browsing, invite를 진행해 양방향 연결 형태로 구현되었고 연결 불안정의 문제가 발생했습니다. PassthroughSubject 이용해 invite 받았는지를 파악하고 받은경우 더이상 invite를 보내지 않도록 stopbrowsing하여 단방향 연결 상태를 유지하도록 했습니다.

연결성 문제

PeerConnection connectedHandler (advertiser side) - error [Unable to connect].
PeerConnection connectedHandler remoteServiceName is nil.
[GCKSession] Not in connected state, so giving up for participant [1C22D602] on channel [0].ll

위와 같은 오류들이 발생하며 MPCSession이 Connected 상태가 된 이후 바로 Disconnected되는 상황이 발생했습니다.

처음에는 연결 성공이 랜덤으로 발생한다고 생각했지만, 여러가지 환경 통제 방식의 빌드 테스트를 통해 p2p wifi 연결 상태에서만 불안정하고 일반 wifi 연결 상태에서는 연결이 안정적인 것을 발견했습니다. 테스트를 해봐도 코드 상의 문제는 없어 보였고, 동일한 코드에서 와이파이 종류에 따라 연결 상태가 다를 수 없을 것이라 생각해 코드 외적인 부분을 살폈고 문제를 찾을 수 있었습니다. p2p 와이파이 연결을 위해서는 로컬 네트워크 권한이 반드시 필요한데, 초기 셋팅 과정에서 추가한 권한이 PR 충돌 해결과정에서 누락되며 권한조건이 사라진 상태였습니다. 권한 다시 추가하였고 연결 상태가 모두 정상임을 확인할 수 있었습니다.

기기 간 방향 파악 문제

NI 이용해 기기 간 거리와 방향을 측정하는 시점에서 두 기기 중 한 기기에서 방향만 측정이 안되는 상태를 발견했습니다.

동일한 메서드에서 거리와 방향을 측정하게 되는데, 방향만 측정되지 않는다는 점에서 기기 문제를 떠올렸고, 다른 기기와 교차검증을 시도했습니다. 그 결과 1개의 기기에서만 방향이 측정되지 않는것을 확인할 수 있었고, 기기 문제로 결론내렸습니다. NI를 위해서는 U1칩이 필요한데, 기기에서 그 부분에 문제가 있는 것 같습니다. 하지만 시도해볼 수 있는 기기의 수가 한정적이었기 때문에 100퍼센트의 확신을 할 수는 없는 상태입니다.