Использование только RTMFP для случайного сопоставления (Adobe Cirrus)

Question

Я пытаюсь найти лучший способ сделать случайное совпадение в простой игре.

При экспериментировании с netStreams с использованием Adobe Cirrus я могу легко настроить прямые подключения, отправлять данные, текст, видео, звук с помощью Cirrus, что отлично. Мне очень легко получить простую связь P2P, и она работает так же, как и мне.

Но я действительно хочу, чтобы реализовать случайную функцию сватовства, используя ТОЛЬКО усик так все хотя p2p ...

Как бы идти о захвате случайных сверстников в той же группе, что ... не в прямой связь с кем-то еще?

некоторые идеи:

-Я думал, может быть, я мог бы использовать репликацию объекта ... и когда кто-то подключается к GroupSpecifier, я мог бы выдвинуть еще один объект в этой общей массив, который имеет локальный peerID и их статус , то я мог бы просто изменить массив, когда theyre в игре. Но потом я беспокоюсь, что нет гарантии, что их запись будет удалена, если человек просто закрывает веб-окно.

-I также думал о том, чтобы просто делать «сообщение» группе, содержащей nearID, а другие сверстники могут получить сообщение ... и те, которые не находятся в игре, будут пытаться и направлять обратно. Затем эта сторона подключится к ним. поэтому они оба будут в прямом соединении друг с другом. Но тогда я чувствую, что, если потенциально 100 людей, которые «доступны» ... получают почту ... тогда все они пытаются подключиться к одному человеку, тогда это может вызвать проблемы.

-Также я думал о том, чтобы просто делать sendToNearest ... но не было бы это не лучшим способом совпадения людей ... потому что у вас может быть только так много соседей, которые я думаю ... если бы было 1000 человек в группа. вы можете только подключиться к нескольким сверстникам, которые на самом деле считали вашего соседа правильным? Тогда в основном вы могли бы закончить просто совпадение с теми же 5-10 людьми или же технически считаться соседом.

Answer 1

Я не думаю, что есть способ избежать тайм-аутов и повторений при совпадении узлов, учитывая, что 1) существует неизвестная и переменная сетевая латентность, а 2) соединения могут соединяться и уходить в неизвестные моменты времени.

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

• Я сочетается с другим узлом
• У меня есть запрос на матч выдающийся
  • Мой выдающийся запрос матча к узлу X

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

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

В этом случае вы можете сократить объем сетевого трафика, необходимый для синхронизации узлов, создав алгоритм сортировки таким образом, чтобы все узлы знали заранее, кто их лучшие совпадения, и попытайтесь напрямую подключиться к их наилучшие совпадения с минимальным сетевым трафиком (без сообщений широковещательного сообщения, а не случайных попыток).

Ключом к этому будет peerID, который автоматически получает каждый узел в NetGroup. Когда узел получает сообщение NeighborConnect, он также содержит уникальный peerID соседнего узла. Другими словами, каждый узел имеет уникальное имя (которое в основном представляет собой большое случайное число) и знает уникальные имена всех других узлов.

Этот peerID длинный, что-то вроде 256-бит. Вы можете создать с ним порядок сортировки - возможно, что-то вроде: учитывая первые 32 бита как int, XOR - удаленный узел peerID с вашим собственным peerID и сортировать удаленные узлы от самого низкого до самого высокого.

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

Это, вероятно, не идеальное решение - вероятно, существует лучший вариант, но я думаю, что это лучше, чем попытки случайных узлов или использования широковещательных сообщений.