Для большого школьного проекта мы сделали P2P-вариант знаменитой пивной игры. Графический интерфейс встроен в JavaFX.
Я должен провести исследование о том, как проверить сценарий атрибута качества, а именно:
100 игроков могут подключиться к игре и играть в нее.
Подключение к игре происходит через вход в GUI, где игрок должен указать IP-адрес (с портом, если он через WAN) хоста (gameleader). Мы реализуем RAFT как алгоритм согласования состояний.
Первым шагом, который я сделал, было исследование наилучшего возможного способа создания 100 клиентов / компьютеров, как бы вы это ни называли. Я быстро пришел к выводу, что Docker был единственным программным обеспечением, в котором одновременно могли работать 100 контейнеров. Моя настоящая проблема заключается в том, как протестировать приложение в контейнере.
Я думал об этом, и единственный реальный способ протестировать процесс игры в каждом контейнере - это пройти через элементы пользовательского интерфейса с другими настройками для каждого клиента (каждый клиент должен присоединиться к игре с разными именами пользователей) с некоторыми вид инфраструктуры тестирования пользовательского интерфейса, такой как TestFX.
Я нашел платформу, которая позволяет вам тестировать пользовательский интерфейс, но для его работы требуется хост-операционная система с графическим интерфейсом (или, по крайней мере, это предположение, которое я основал на кратком поиске в Интернете).
Может быть, есть способ сделать это в самом IntellJ. Создание 100 контейнеров с игрой с каждым уникальным IP-адресом, чтобы они могли подключаться к хосту игры.
Редактировать для @Karol Dowbecki
То, как мы общаемся, отправляет сериализованные AppendEntries (сердцебиения) каждые 100 мс по TCP / IP с UPnP, которые содержат изменения, которые должны быть зафиксированы (если ничего не произошло, то в appendentry нет журналов). Таким образом, если игрок выполняет действие, он отправляет AppendEntry в этот момент лидеру (gameleader / host), который затем передает его обратно всем остальным узлам и ожидает, пока большинство узлов отправит его обратно (двухфазный). commit) после чего он добавляется в список логентов каждого игрока (все данные игры). Если новый игрок присоединяется к игре, он получает все logEntries, которые существуют для этой игры, всего за 1 такт, который является гигантским сериализованным объектом json, после чего он пересчитывает шаги (logEntries) снизу вверх до последнего , который игрок присоединился к игре.
Так что вы предлагаете захватывать эти сериализованные приложения, которые проходят по сети, десериализуют их и сравнивают с ожидаемым результатом? Это будет очень сложно, если мне придется сканировать каждую AppendEntry, поскольку каждый клиент отправляет 10 из них в секунду лидеру (если клиент является игроком) и 10 на все узлы (если клиент является лидером / хостом) .
Также AppendEntries ходят взад и вперед. Каждый раз, когда игрок присоединяется к LogIndex (индекс LogEntries, в основном индекс того, сколько изменений игрового состояния произошло) увеличивается на 1, что в конечном итоге определяет, сколько изменений произошло в игровом состоянии. Так что я не посылаю статическую информацию туда-сюда. Это меняется с каждым присоединяющимся игроком. Также, когда игрок «отключается», это снова влияет на LogIndex. Я должен быть в состоянии отследить тот факт, что 100 человек присоединились к игре и все еще там.