Как MVC Pattern может быть реализован в многопользовательском приложении RMI?

Question

Я пытаюсь создать фреймворк / библиотеку / API для создания небольших многопользовательских игр, цель которых - добиться «развязки» между сервером, клиентом и бизнес-логикой.

Сервер в моем случае как бы регистрирует клиентов и отправляет список бизнес-логики, клиенты регистрируются на сервере, и бизнес-логика выполняет игровую логику и обновляет клиента, получая список клиентов с сервера.

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

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

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

большое спасибо

jibby

Answer 1

Если вы собираетесь использовать эту среду для игр в реальном времени, я бы посоветовал не использовать RMI - она ​​не предназначена для такого рода вещей. Также имейте в виду, что двусторонний RMI между машинами в разных подсетях очень трудно заставить работать.

Похоже, вам нужно, чтобы клиенты были проинформированы сервером о возникновении событий. Когда ваш клиент подключается, он может найти удаленный объект в реестре RMI сервера и вызвать метод для этого, чтобы передать удаленный объект, который он создал (размещенный на клиенте), на сервер. Сервер должен будет поддерживать коллекцию этих клиентских объектов и перебирать их для отправки событий. Это сложная архитектура, чтобы понять, что если сеть выходит из строя или клиент отключается, вам придется иметь дело со всевозможными неприятными обработками ошибок и зависаниями. Я бы порекомендовал вам поддерживать большую часть общения в одном направлении - от клиента к серверу. Также сделайте это максимально простым - просто удаленный объект на сервере с различными методами, которые принимают Serializables в качестве параметров и возвращают Serializables.

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

Самой сложной задачей в этой задаче, безусловно, будет получение кода на сервере, который уведомляет клиентов правильно, поскольку он должен быть многопоточным и корректно обрабатывать ошибки - удачи!