OGP, Online Game Protocols #

이 글은 생각나는대로 편집중입니다. 탈고하지 않은 상태이므로 유념하여 봐 주세요.

Protocol Base #

프로토콜 베이스, 즉 가장 기본적인 약속을 말한다. 프로토콜 베이스는 1) 개개의 패킷을 구분하는 방법과 2) 패킷의 구조를 의미한다. 일반적인 프로토콜에서는 PC통신 방식의 Line Buffering 방식도 이용되지만, 최근의 온라인게임에서는 Binary Structured Packet이 가장 많이 사용되어진다.

Line 기반 Text 프로토콜 #

한 라인의 끝인 CR 혹은 LF를 기준으로 하여, 하나의 패킷으로 취급하는 통신방식이다. HTTP, TELNET, FTP, NNTP, SMTP, rlogin 등 대부분의 유명한 인터넷 소프트웨어들은 이 방식의 기반프로토콜로 구성되어 있다. 인터넷의 초창기를 지휘하던 unix 서버들의 콘솔특성에서 유래된 듯하다.

이 프로토콜은, 오류에 강하고 디버깅이 용이하지만 CR 이나 LF를 만나기 전까지 얼마만큼이 하나의 패킷인지 알 수 없고, 하나의 패킷을 전송받았다고 하더라도 별도의 파싱을 통해 파라미터들을 분리해내야 하므로 - 덩달아 문자숫자를 숫자로 바꾸는 일마저 해야 한다 - 프로그래머들이 대체로 싫어하는 경향이 있다. 즉, 안정성/디버깅편리성은 우수하지만 개발이 까다롭다. 유연성이 좋다.

 
  구현예 (송신)
    sprintf(packet, "%d %d %d %s\n", packet1.id, packet1.count, packet1.action, packet1.charname);
    socket.send(packet, strlen(packet));

  구현예 (수신)
    nsize = DetectCR(socket.recvbuffer); // 1개의 패킷 완성 확인
    if(!nsize) return;
    
    memcpy(packet, socket.recvbuffer, nsize); // 수신버퍼로부터 복사
    ParseString(packet, " ", arr_packet); // 패킷 요소 구분 
    ...

Structure 기반 Binary 프로토콜 #

구조체를 통째로하여 바이너리로 전송하는 방식이다. 1바이트의 오류만으로 통신이 끝장나는 치명적인 단점을 가지고 있지만, 구조체 그대로 전송하고 전송받을 수 있으므로 프로그래머들이 선호한다. 안정성/디버깅편리성이 떨어진다. 유연성이 없다. 개발이 쉬운편이다.

 
  구현예 (송신)
    socket.send(&packet, sizeof(packet));

  구현예 (수신)
    if(ispacket(socket.recvbuffer))  // 1개 패킷완성검사
        memcpy(packet, socket.recvbuffer, sizeof(packet)); // 패킷 구조체로 복사
    ...

Protocol Version #

Request Timeout #

Flexibility #

개발 단계에서 자주 발생하는 파라미터의 갯수변화나 데이터의 범위변화에 대해서 프로토콜은 버전을 올리지 않더라도 바로 처리할 수 있도록 작성되어져 있어야 한다. 예를 들어 정수 4개를 실어 보낸다고 할 때에 다음 두가지 상황을 고려해 보자. 많은 개발자들은 단지! 프로그래밍하기 쉽다는 이유만으로 1)과 같은 설계를 해버리고싶은 강한 유혹을 받는다.

// #1
// 숫자를 3자리로 제한하여, 빈자리 0 을 채우도록 한다.
// 예) 001:002:003:004

// #2
// 숫자자리수에 제한하지않는다.
// 예) 1:2:3:4

어떤 이유에 의해서 3자리를 초과하는 숫자가 전달되어 올 수도 있고, 파라미터가 5개 이상이 올 수도 있다. 프로그램은 이런 넌크리티컬 오류들에 대해서도 대비를 해야 하지만, 프로토콜도 이 정도의 유연성을 가지고도록 설계 되어야 한다.