웹소켓및 스프링 웹등은 메시지 기반의 멀티플레이어 게임을 만들기 위한 도구일뿐이며
메시지 설계는 직접해야합니다. 여기서는 액터패턴을 일부사용하였으며
설명을 위해 UML TOOL(STAR UML)을 이용하였습니다.
AKKA의 액터를 이용한 버젼과, 전통적인 스레드를 사용하는 동일한 기능을 하는 두가지 버젼을 준비하였습니다.
스레드 버젼은 프로타잎용으로 먼저작성을 하였고, 이후 액터버젼으로 추가구현을 하였습니다.
두가지는 완전하게 같은 서버로직을 가지고 있으나 약간의 다른 패턴을 사용하였습니다.
그리고 이것은 불완전하기 때문에 지속적인 개선이 필요합니다.
여기서 Actor는 처리가능한 서버로직입니다. 게임에 입장하기 전까지 UseCase를 통해 정리해보는것입니다.
UserCase 구상이 완료되면, 실제 메시지를 처리할 인스턴스를 작성하고 구조적으로 배치해야합니다.
AKKA System을 선택한 이유는, 액터를 잘 설계한다고하면, 코드의 큰 수정없이 클러스터로 확장이 용이합니다. - https://doc.akka.io/docs/akka/2.5/cluster-usage.html#a-simple-cluster-example
당장은 클러스터를 크게 신경쓰지 않고 진행을 하겠습니다.
아직은 아무기능이 없으며 서버 기능을 하는 액터를 옹기종기 잘 모아 놓습니다.
그 다음 해야할일은 메시지 흐름을 구체화하는것입니다.
액터에 실제 메시지흐름을 정의하고 이 베이스로 액터의 메시지 흐름을 처리하는 코드를 작성할것입니다.
게임에 접속하고, 멀티플레이를 위한 테이블 공간에 참여시키는 메시지 시퀀스 다이어 그램
액터의 메시지는 오브젝트의 패턴매칭을 통해 분기처리가 가능합니다.
조금더 진보된 방식의 switch 구문이라고 보면 되겠습니다.
최근 모던 언어들은 대부분 패턴매칭을 언어 자체에서 지원하는 경우가 많습니다.
@Override
public AbstractActor.Receive createReceive() {
return receiveBuilder()
.match(ConnectInfo.class, c -> {
if(c.getCmd()== ConnectInfo.Cmd.CONNECT){
sessionMgr.put(c.getSessionId(),c.getWsSender());
log.info("user connected:"+c.getSessionId());
}else if(c.getCmd()== ConnectInfo.Cmd.DISCONET){
sessionMgr.remove(c.getSessionId());
Player removeUser = new Player();
removeUser.setSession(c.getSessionId());
if(c.getTableNo()>0){
findTableByID(c.getTableNo()).tell(new SeatOut(removeUser),ActorRef.noSender());
}else{
findTableALL().tell(new SeatOut(removeUser),ActorRef.noSender());
}
log.info("user disconnected:"+c.getSessionId());
}
sessionMgr.put(c.getSessionId(),c.getWsSender());
})
.match(TableCreate.class, t->{
// Create a table under the lobby, if you have an Actor named TableManagement, you can move easily.
String tableUID = "table-" + t.getTableId();
if(t.getCmd() == TableCreate.Cmd.CREATE){
ActorRef tableActor = getContext().actorOf( TableActor.props(t,this.getSelf() ), tableUID);
tableActor.tell(t,ActorRef.noSender());
}
})
.match(JoinGame.class, j->{
joinGameTable(j.getTableId(),j.getName(),j.getSession());
})
.match(MessageWS.class, m->{
send(m.getSession(),m.getGameMessage());
})
.build();
} |
액터의 중요한 속성중 하나인데, 액터는 그 어떤 액터와 상태 공유를 하지 않습니다. ( 할수없습니다.)
그래서 익숙한 도트접근을 통해 로컬에서 개발되었다고 해도 그어떤 값도 얻어 낼수 없습니다.(메모리 공유를 원천 차단합니다.)
| OOP | ACTOR |
|---|---|
Lobby a; a.getTable(1).getTableName(); | LobbyActor a; TableActor b; b.tell("some ask",a) |
로컬에서 구현이 복잡해지는 단점이 있으나, 리모트로 확장시 구현의 차이가 없어진다는 장점이 있습니다.
private ActorRef findTableByID(int tableID) throws Exception {
String tableActorPath = "/user/lobby/table-"+tableID;
ActorSelection tableSelect = this.getContext().actorSelection(tableActorPath);
FiniteDuration duration = FiniteDuration.create(1, TimeUnit.SECONDS);
Future<ActorRef> fut = tableSelect.resolveOne(duration);
ActorRef tableActor = Await.result(fut, duration);
return tableActor;
} |
상대의 액터주소만 알고 있다면 , 원격지라 할지라도 상대의 액터 객체를 알지못해도 통신이 가능합니다.
객체를 통한 전송
ActorRef someActor = system.ActorOf(........);
someActor.tell("some message",null); |
주로 로컬에서 활용되며, 액터는 생성시점 액터참조를 바로 얻을수 있습니다. 하지만 상대 액터가 가진
멤버접근을 통한 정보 획득은 불가하며 로컬이라 할지라도 tell 로 질의를 해야합니다.
ActorSelection lobbyActor = system.ActorSelection("user/lobby");
lobbyActor.tell("some message",null);
// 자식의 모든 요소 선택이 가능합니다.
ActorSelection tableAllActor = system.ActorSelection("user/lobby/table/*");
tableAllActor.tell("some message",null); |
ActorPath를 통한 여러 지점에으로의 우아한 메시지 전송을 다음 링크를 통해 살펴볼수 있습니다.
Actor를 심화학습하고 싶다고 하면, 아래를 조금더 살펴보면 됩니다.
또한 메시지 처리에서 Thread와 Actor를 비교해보는것은 , 메시징 처리를 위한 좋은 학습자료가 될것입니다.