Использование только RTMFP для случайного соответствия (Adobe Cirrus) - PullRequest
8 голосов
/ 09 марта 2012

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

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

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

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

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

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

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

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

1 Ответ

1 голос
/ 17 апреля 2012

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

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

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

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

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

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

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

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

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

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

...