Интерфейс Multipeer Connectivity для до 45 устройств

Я надеюсь использовать инфраструктуру Multipeer Connectivity и буду благодарен за любой голос о том, как лучше всего продолжить.

Мне нужна связь между устройством "тренера" и устройствами с 45 "плеерами". Все они будут находиться в одном и том же пространстве, но не смогут предсказать доступность или соединение Wi-Fi. Каретному устройству необходимо отправить инструкцию (небольшой пакет данных) всем устройствам плеера каждую секунду. Каждому "игроку" требуется отправить показания с монитора Bluetooth Heartrate (очень маленький пакет данных) обратно на каретку каждую секунду. Поскольку максимальные точки за сеанс равны 8, будет ли любая из этих идей работать с теми числами, которые мне нужны?

a) Первые 7 игровых устройств для установления соединения с тренером рекламируют другой тип сеанса и позволяют 7 (или это будет 6?) больше игроков присоединиться к ним. Эти первые 7 выступают в качестве посредника к другому 49 (или 42?), Передавая инструкцию от тренера и передавая собранные показания тренеру. Несколько секундное отставание между инструкциями и показаниями сердечного ритма не является предпочтительным, но все будет в порядке.

b) Устройство тренера создает и рекламирует один сеанс. После подключения 7-игровых устройств тренерское устройство создает еще один сеанс и повторяет еще 7. Повторяйте, пока все устройства плеера не подключены к карете. Это кажется маловероятным для работы, но без понимания магии, которая является Multipeer Connectivity, это был вариант, который приходил на ум.

c) Тренер устанавливает сеанс с игровым устройством 1, которое подключается к устройству 2... в топографической цепочке. Когда каждое устройство получает инструкцию, оно добавляет его собственное чтение в пакет данных и отправляет его. Последнее устройство возвращает весь пакет тренеру. Я не могу предсказать, сколько времени потребуется для раунда данных, и это также кажется неприятным, если одно устройство покидает группу.

Понятно, что любые советы или мнения об использовании схемы соединений Multipeer для 45 или около того устройств будут оценены.

ОТВЕТЫ

Ответ 1

Я размышлял о чем-то подобном в последнее время, и я бы сказал в вашем случае b) был бы вашим лучшим вариантом, если вам не нужны "игроки", чтобы общаться друг с другом.

Multipeer Connectivity поддерживает несколько сеансов, поэтому вы можете иметь массив для объектов сеанса, рекламировать как "тренер", и каждый обнаруженный игрок либо приглашает на последний сеанс, если он имеет емкость, либо создает новый.

Объект вашего игрока может хранить ссылку на сеанс и peerID для целей отправки данных и, возможно, содержать словарь отображаемых имен peerID, сопоставленных с соответствующим объектом игрока для обработки входящих данных.

Таким образом, у вас также нет прыжков между данным "игроком" и "тренером", в отличие от а) и в).

Очевидно, настоящий трюк здесь - это тестирование. Я сам не владею 8+ устройствами, и я до сих пор не уверен, как я буду тестировать свою собственную реализацию!

Edit

Я ответил на аналогичный вопрос с фактическим кодом здесь: Лучший вариант для потоковой передачи данных между iPhones

Ответ 2

Я знаю, что это старый вопрос. У меня была та же проблема, что и раньше (и задал подобный вопрос без четкого ответа).

Вещи, которые я тестировал, и проблемы:

  • "Обычный способ" - один сеанс.

    • Проблема: максимум 8 устройств.

  • Массив сеансов, поместив 6 устройств на каждый сеанс (чтобы избежать максимума 8)

    • Проблема: много перегрева, памяти и потребления процессора. Когда несколько устройств из нескольких сеансов будут отключены одновременно, восстановление может занять много времени, чтобы быть воспринятым.

  • Это самый сложный способ.

    Шаги:

    • Мы создаем сеанс и допускаем максимум 4 - 5 клиентов.
    • Каждый раз, когда клиент подключается, он создает группу с теми же условиями.
    • Когда мы достигнем максимального количества клиентов (4 - 5 в зависимости от вашей реализации), мы прекращаем рекламу.
    • Новые клиенты будут связаны между собой, как ячейки. Хитрость заключается в том, чтобы иметь некоторый метод для выбора сеансов, которые новый клиент должен подключить к упорядоченному по приоритету, и создать метод повторного распространения трафика на клиентский сеанс на "серверный репликатор".

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

Ответ 4

по умолчанию 8, это не максимум,

вы сомневаетесь меня, так как мне понадобится больше 8!

он должен быть плохо написанным, исправленным ниже.

maximumNumberOfPeers Максимальное количество одноранговых узлов разрешено в сеансе, включая локальный одноранговый узел. @property (назначить, неатомный) NSUInteger maximumNumberOfPeers обсуждение Наибольшее допустимое значение (и значение по умолчанию) равно 8.

https://developer.apple.com/library/ios/documentation/MultipeerConnectivity/Reference/MultipeerConnectivityFramework/MultipeerConnectivityFramework.pdf