Сеанс многорангового подключения в iOS7

Я просмотрел документацию Apple, но до сих пор не понял одну вещь, сессию.

  1. Когда - (void)advertiser:(MCNearbyServiceAdvertiser *)advertiser didReceiveInvitationFromPeer:(MCPeerID *)peerID withContext:(NSData *)context inventoryHandler:(void (^)(BOOL, MCSession *))invitationHandler вызывается, нам нужно передать сеанс в обработчик приглашений. Что будет с этой сессией? Когда A приглашает B присоединиться к сеансу, созданному A, предоставляет ли B новый сеанс также и A? Что находится внутри сеанса B? Это только один A или он включает всех пиров, которые в настоящее время находятся в сеансе A? Должен ли B отслеживать сеанс, который использовался для принятия приглашения A? В этой статье, http://nshipster.com/multipeer-connectivity/, руководство создает новый сеанс на лету и использует его для принятия приглашения, не потеряете ли вы сеанс после завершения функции; таким образом теряя информацию подключенным пирам?

  2. Предположим, что B, C и D приглашены A, и теперь B хочет отправить что-то C. Требуется ли, чтобы B сначала отправил информацию A, или B может отправить информацию непосредственно C?

  3. Согласно документации Apple, один сеанс может содержать не более 8 пиров. Можно ли создать массив сеансов, чтобы вы могли пригласить более 8 человек присоединиться к вашему устройству? Если это так, должен ли клиент также отвечать массивом, чтобы он мог содержать более 8 одноранговых узлов в своем списке?

  4. Предположим, что A и B теперь подключены, и теперь A приглашает C присоединиться. Как B узнает, что C сейчас находится в сеансе?

Спасибо, что прочитали такой длинный пост.


session multipeer-connectivity ios7
person Alex Su    schedule 31.03.2014    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Документации по многоранговому соединению не так много, поэтому эти ответы основаны на моих собственных экспериментах:

  1. В этом вопросе много вопросов, но в двух словах сеанс(ы) А управляет приглашениями, которые А отправил или принял. Таким образом, если B приглашает, а A принимает, сеанс, который A передает при принятии, затем будет использоваться в обратном вызове MCSessionDelegate session: peer: didChangeState:, чтобы сказать, произошло ли соединение. В этот момент свойство connectedPeers сеанса A будет содержать B (если соединение установлено успешно). Сеанс, который B использовал для отправки приглашения, также получит тот же обратный вызов, как только A примет его, и будет содержать A в connectedPeers. Ни A, ни B не будут иметь никакой информации о сеансе другого, который управлял этим соединением между ними. И да, если вы хотите отправить какие-либо данные вновь подключенному узлу, вам нужно сохранить ссылку на сеанс, который обрабатывал соединение. Я еще не видел никаких реальных преимуществ в создании нового сеанса для каждого приглашения.

  2. Исходя из вышеизложенного, у Б нет информации о том, с кем связан А. Таким образом, если A подключен к B, C и D, единственный одноранговый узел, о котором знает B, — это одноранговый узел, к которому он подключен, — A. Что здесь предлагает Multipeer Connectivity, так это возможность для B обнаружить C или D через A. Таким образом, если AB соединение было установлено через WiFi, а AC через Bluetooth, но у B не включен Bluetooth, а C находится в другой сети Wi-Fi, чем B, B и C все еще могут обнаруживать друг друга через A. Процесс приглашения и принятия все еще продолжается. к B и C, чтобы справиться, хотя.

  3. Я ответил здесь на вопрос об управлении сеансом, который может быть полезен Лучший вариант для потоковой передачи данных между iPhone

  4. B ничего не знает о соединении A с C. Все, что B может сделать, это обнаружить C для себя и добавить C в свой собственный сеанс.

person ChrisH    schedule 01.04.2014
comment
Спасибо! Очень полезно! - person Alex Su; 14.04.2014

arrow_upward
1
arrow_downward

  1. Если быстро просмотреть ответ Криса, он кажется точным из того, над чем я работал на своей работе.

  2. В настоящее время я работаю над игрой, использующей многопользовательское подключение, и обнаружил, что:

    (Предположим, что все подключены к Wi-Fi). Если A подключается к B и A подключается к C, то B будет подключен к C и сможет отправлять сообщения C.

    Multipeer Framework — это платформа P2P, которая автоматически соединяет всех вместе.

    даже если (как в моем текущем проекте) вы настроите его как модель «сервер-клиент», все одноранговые узлы все равно будут подключены, и вы сможете отправлять сообщения между B и C, не проходя через A. В зависимости от того, что вы делаете с вашим приложением.

  3. Перейти с ответом Криса

  4. Адресовано в # 2

Рекомендую посмотреть пример проекта в Apple Docs и внимательно посмотреть, что происходит в области отладки при подключении.

Кроме того, в качестве примечания:

Scenario:(A is only on wifi),(B is on wifi and bluetooth),(C is on bluetooth only)

если A подключается к B через Wi-Fi, а B подключается к C через Bluetooth, A strong> по-прежнему будет подключен к C, но вы не сможете отправить сообщение с A напрямую на C, поскольку они находятся на разных сети.

person SirCharlesWatson    schedule 02.04.2014
comment
Если у вас есть как минимум 3 устройства для тестирования, вам будет намного проще наблюдать за тем, что происходит между всеми устройствами. - person SirCharlesWatson; 03.04.2014
comment
Спасибо! Очень полезно! - person Alex Su; 15.04.2014

arrow_upward
0
arrow_downward

@SirCharlesWatson:

(Предположим, что все подключены к Wi-Fi). Если A подключается к B и A подключается к C, то B будет подключен к C и сможет отправлять сообщения на С.

Multipeer Framework — это платформа P2P, которая автоматически соединяет всех вместе.

У меня вопрос: когда B автоматически подключается к C, получат ли B и C уведомление об изменении состояния существующего сеанса?

  • A: session:peer:B didChangeState(MCSessionStateConnected)
  • B: session:peer:A didChangeState(MCSessionStateConnected)
person fan2    schedule 16.07.2015