ServerSideScripting

UserPreferences

1. 개요
2. 스크립트 시스템이 클라이언트에 있을 때 발생하는 문제
3. 스크립트 시스템이 서버에 있을 때 발생하는 문제
1. 블러킹 문제
2. 다수를 상대로 한 스크립트
3. 실행 성능 문제
4. 루아(LUA)를 사용한 서버사이드 스크립트
5. 참고

1 개요

클라이언트/서버 환경에서 어떻게 스크립트를 잘 사용할 수 있을까?

일반적인 클라이언트 only, 즉 입력과 처리가 같은 머신에서 이루어지는 경우의 스크립트 모양을 생각해 보자.

게임이 시작되어 유저가 자신의 이름을 입력하면 NPC가 이름과 함께 인삿말을 하는 스크립트!



$USERNAME = gets(); 
greeting = "안녕하세요. " + $USERNAME + " 씨"; 
say(greeting); 


이런 스크립트를 클라이언트/서버 환경에서 쓰고자 한다면 어떤 문제가 발생하는가?

2 스크립트 시스템이 클라이언트에 있을 때 발생하는 문제

스크립트를 실행한 결과값이 어떻게든 유저의 데이터값에 영향을 미치는 경우, 클라이언트는 이를 서버에다 변경하라고 알릴 것이다. 문제는 서버에는 스크립트 시스템이 존재하지 않기 때문에, 클라이언트가 보내온 값이 정상적인 것인지를 검사할 방법이 없다는 것이다. 그렇다고 스크립트 자체를 유저의 데이터값에 영향을 미치지 못하도록 설계한다면 쓸모없는 스크립트가 되어버린다.

그리고 클라이언트가 스크립트 시스템을 가지고 있을 경우, 다수의 클라이언트에 동시에 영향을 미치며 그 결과값을 취해야하는 스크립트는 실행이 곤란하다. 이 문제는 어떻게 해 볼 수가 없는 문제다.

위의 문제점들을 고려해봤을 때 스크립트 시스템을 클라이언트에 두는 것은 이모저모로 문제가 많은 것 같다.

3 스크립트 시스템이 서버에 있을 때 발생하는 문제

3.1 블러킹 문제

클라이언트 only 환경에서는 위 예제의 gets() 함수가 임의의 문자열을 리턴하기 전까지 화면이 정지, 즉 블러킹되어도 별 문제가 없다. 하지만 서버에서 유저 한 명의 입력을 받아들이기 위해 전체 시스템이 정지한다면 말이 안 된다. 이 문제를 해결하기 위해서는...

스크립트 시스템이 Preemptive Multi-tasking 또는 그 비슷한 방법을 지원해야한다. 그런 기능이 없다면 스택의 세이브/로드 기능과 스크립트를 파일 중간에서부터 실행할 수 있는 기능이라도 있어야한다.

유저의 입력 자체는 어차피 문자열이나 숫자 등의 간단한 포맷으로만 이루어지기 때문에 별로 문제가 안 된다. 이런 입력을 받아들일 수 있는 버퍼를 각 클라이언트 별로 만들어둔다.

스크립트를 실행하는 도중에 유저의 입력을 필요로 하는 함수를 만나면 스크립트 시스템은 실행을 멈추고, 서버 쪽으로 리턴한다. 서버는 유저에게 입력이 필요하다는 패킷을 날리고, 패킷이 오기 전까지 스크립트를 실행하지 않는다. 유저로부터 패킷이 날아오면 버퍼를 채우고, 다시 스크립트를 아까 중단했던 지점에서부터 재실행한다.



3.2 다수를 상대로 한 스크립트

서버에 스크립트 시스템이 존재하는 경우, 다수의 클라이언트에게 동시에 영향을 미치는 스크립트를 만들 수 있다. 예를 들어 "임의의 방 안에 있는 모든 클라이언트들에게 문제를 내고, 답을 제일 빨리 맞춘 클라이언트를 제외한 다른 이들에게 벌칙을 내린다." 같은 스크립트 말이다.

이것은 위의 시스템이 구현되어 있다면 그렇게 어려울 것 같지는 않을 것 같다.



3.3 실행 성능 문제

선점형 멀티태스킹이 가능한 스크립트 시스템이 있다고 해도, 이걸 서버에서 쓸 수 있는지는 명확하지 않다. 어떤 기능을 하는 서버냐에 따라 다르겠지만, 일반적인 게임 서버일 경우 적어도 1000명 이상의 클라이언트가 접속해 있다고 생각한다면 왠만한 스크립트 시스템은 제대로 성능이 나오지 않을 것이다. 이 문제는 지금으로서는 스크립트 시스템을 클라이언트에 내리는 수 밖에 없다고 생각한다.

4 루아(LUA)를 사용한 서버사이드 스크립트

루아가 5.0부터 다행히도 coroutine이라는 것을 제공해서 선점형 멀티태스킹 비슷한 것을 만들 수 있게 되었다. 이로서 스크립트 시스템이 서버에 있을 때 발생하는 가장 중대한 문제인 블러킹 문제를 해결할 수 있게 되었다. 다음의 소스를 보자.


systemQuestion = ""
systemAnswer = ""
LUAVM_INPUT_BUFFER = {}

function ask(...)
    local i = 1
    while i <= arg.n do
        if i == 1 then
            systemQuestion = arg[i]
        else
            systemAnswer = systemAnswer + "|" + arg[i]
        end
        i = i + 1
    end
    
    while true do
        -- 버퍼에 들어있는 유저 입력이 없다면 
        -- 클라이언트에게 패킷을 보내라고 알려주고
        -- 실행을 중지한다.
        if (table.getn(LUAVM_INPUT_BUFFER) == 0) then
            POST_INPUT_REQUEST()
            coroutine.yield("")
        -- 버퍼에 입력이 있다면 리턴하면 된다.
        -- 리턴하기 전에 버퍼에서 지워야한다.
        else
            local return_value = LUAVM_INPUT_BUFFER[1]
            table.remove(LUAVM_INPUT_BUFFER, 1)
            return return_value
        end
    end
    
    return ""
end

coroutine.yield("")라는 부분이 보이는데 이는 루아 VM의 실행을 중지하고 C/C++ 쪽으로 실행 컨텍스트를 돌려준다. 이 함수를 이용하면 유저의 입력을 저장하는 리스트가 차 있을 경우에는 이를 이용해 스크립트를 계속 실행하고 아닐 경우에는 유저에게 입력을 요구하는 패킷을 보낼 수 있게 되는 것이다. POST_INPUT_REQUEST 함수가 이 역할을 하는 C 함수다.


int POST_INPUT_REQUEST(lua_State* L)
{
    LuaVM* pLuaVM = LuaVM::getLuaVM(L);
    AssertRead(pLuaVM);
    
    MSGQuestion msgQuestion;
    msgQuestion.setQuestion(LuaAPI::getLuaString(L, "systemQuestion"));

    Tokenizer t("|", "", false);
    t.tokenize(LuaAPI::getLuaString(L, "systemAnswer"));
    for (size_t i=0; i<t.size(); i++)
    {
        msgQuestion.enqueueAnswer(t.at(i));
    }

    pLuaVM->getClient()->sendPacket(&msgQuestion);
    
    return 0;
}

5 참고

• Scripting in C using Co-Routines
  
• Portable Coroutine Library
  

• see also Lua
  

• CategoryLanguage, CategoryAppProgramming