캡틴아메리카-시빌워 다들 보셨나요?

전 세계적으로 흥행 중이라 그런지 프라우드넷을 사용한 마블퓨처파이트도 덩달아 흥행 중이라 합니다!

자세한 내용은 기사 보기를 눌러 주세요~

기사 보기

게임을 개발하다 보면, "두 기기 간의 시간 동기화를 하는 방법"이 필요할 때가 있습니다.

이것에 대해서 알아 봅시다.

두 기기의 시간을 동기화하는 것은 일반적으로 round trip latency (RTT)를 이용하는 방법입니다.

기기 A,B가 있다고 있다고 칩시다.

* A->B: A의 시스템 시간을 보낸다.[1]

* B->A: [1]을 그대로 보낸다.

A에서는 A의 시스템 시간에서 [1] 안의 시간을 빼면 RTT를 얻게 됩니다.

이제,

* A->B: RTT[2]와 A의 현재 시간[3]을 보낸다.

이렇게 하면 됩니다. B에서 A의 현재 시간을 얻고 싶으면,

* A의 현재 시간 = [3] + [2]/2

를 계산하면 됩니다.

NTP도 이와 비슷한 방식으로 작동합니다.

컴퓨터 네트워크의 특징상 RTT는 한번만 측정한다고 정확하다고 말할 수 없습니다. 매번 RTT는 조금씩 틀리기 때문입니다. 무선 네트워크에서는 크게 틀리는 경우도 있습니다.

따라서 여러번 잰 후 최근 것의 평균을 내는 것이 더 정확합니다.

참고로, 프라우드넷(proudnet.com)에서 다양한 시간 동기화 함수를 제공합니다. 

* CNetClient.GetIndirectServerTimeMs

* CNetClient.GetP2PServerTimeMs

* CNetClient.GetServerTimeMs

프라우드넷은 서버 뿐만 아니라 P2P 연결된 다른 클라이언트와의 RTT를 얻는 기능도 제공합니다.

CNetClient와 CNetServer의 GetLastPing와 GetRecentPing 함수를 이용해서 말이죠.

안녕하세요, 넷텐션입니다.

오랜만에 개발 이야기로 인사 드립니다. (_ _)

신년부터 애플의 IPv6 관련 리젝트 정책으로 개발 업계가 술렁이는데요,

넷텐션에서 리젝트 안 당하는 법을 알려 드립니다!

1. 네트워킹 프레임 워크를 사용할 것

2. IPv4 전용 API를 쓰지 말 것

3. 하드코딩 주소를 쓰지 말 것

----------------

 

1. 네트워킹 프레임워크를 사용할 것 

 

iOS SDK 자체에 있는, 소켓 윗단에 구현되어 있는 네트웍 프레임워크라던지, 혹은 제3의 네트워크 프레임워크를 쓰는 것을 권장한다는 뜻입니다. 네트웍 프레임웍을 쓰신다면 위 2는 웬만하면 고려 안하셔도 될 것입니다. 만약 써드파티 네트웍 프레임웍을 쓰시고 있으시면, 해당 프레임웍 개발자에게 이 질문을 꼭 하셔야 하겠습니다. "IPv6 지원하나요?"

 

네트웍 프레임웍의 일종인 프라우드넷은 IPv6에 대응되어 있습니다. 2015년 12월 업그레이드 릴리즈에서 대응했습니다. 프라우드넷을 쓰시는 분은 IPv6 지원을 원하시면 2015년 12월 업그레이드 혹은 이후 릴리즈를 적용하셔야 합니다. 

 

----------------

 

2. IPv4 전용 API를 쓰지 말 것

 

직접 소켓 프로그래밍을 하신다면, IPv4 전용 API를 쓰시면 안됩니다. 가령 이런 함수들을 쓰시면 안됩니다. (이런 함수들을 쓰는 것 자체가 애플에서 리젝되는지는 확인되지는 않았습니다만, 아무튼 프라우드넷에서는 이들 함수들을 전혀 쓰지 않습니다.)

 

inet_addr()

inet_aton()

inet_lnaof()

inet_makeaddr()

inet_netof()

inet_network()

inet_ntoa()

inet_ntoa_r()

bindresvport()

getipv4sourcefilter()

setipv4sourcefilter()

 

IPv6에서 잘 작동하는지 테스트하려면, IPv6 주소만 있는 네트워크 환경을 만들어야 합니다. 여러가지 방법이 있는데요, 저희의 경우 맥 기기를 이용해서 만들었습니다. 

 

----------------

 

3. 하드코딩 주소를 쓰지 말 것 

 

애플에서는 '하드코드 주소'라고 표현했는데요, 이는 대중들에게 쉽게 의미를 전달하려고 일부러 저렇게 표현한 것 같습니다. 

정확한 명칭은 IP literal입니다. 가령, "11.22.33.44"입니다.

 

한편 우리가 흔히 말하는 '호스트 네임' 가령 "server1.mygame.com" 같은 것은 FQDN(fully qualified domain name)이라고 부릅니다.

 

만약 하드코드 주소 즉 IP literal을 직접 이용해서 서버에 접속하면 어떻게 되냐고요? 일부 IPv6 네트워크의 클라이언트가 IPv4 네트워크의 서버에 접속을 못하는 경우가 발생할 수 있습니다. (iOS 9.2 이후부터는 이 문제가 일부 해결되긴 합니다만 이 또한 모든 IPv6 네트워크에서 된다는 보장도 없습니다.)

 

이 반대도 마찬가지입니다. 클라이언트는 IPv4인데 서버가 IPv6인 경우요.

 

접속을 왜 못하는지는, NAT64/DNS64의 작동 얼개로 설명됩니다. 내용이 길기 때문에 일단 논외 하겠습니다.

 

그럼 어떻게 해야 하느냐? 애플이 지령(?)한대로 따라야 합니다. 서버는 IPv4 literal 대신 FQDN으로 접근 가능해야 합니다. 클라이언트는 서버에 접속할 때 FQDN을 써야 하고요.

 

위 내용을 예로 들어 설명하자면, 

 

- 11.22.33.44 ==> 애플에서 밴 먹임

- server.mygame.com ==> Ok

- 11:22:33:44:55:66:77:88 ==> 애플에서 밴 먹임

 

 

 

서버 세팅을 하시는 분들은, 각 서버에 대한 DNS 세팅을 모두 해주어서 각 서버가 FQDN을 가지게 해주어야 하죠. 그리고 클라이언트는 각 서버에의 접속을 할 때 IP literal이 아니라 FQDN으로 서버에 접속을 해야 하겠죠.

 

만약 각 서버에 대해 지금 당장 FQDN을 배정하기 힘들 때를 위해, 프라우드넷에는 응급처치 방법을 제공합니다.

 

프라우드넷 기반 서버에 접속하는 IP literal을 입력하되, IPv4에 물려있는 다른 서버 X의 FQDN도 추가로 입력하면 됩니다. X는 실제로 접속은 안하니 걱정 마시고요, 그저 DNS 검색 대상만 될 뿐입니다. 이것이 있으면, 100% 보장하지는 않습니다만, [1] IPv4 literal만 갖고도 서버에 접속을 할 수 있습니다. 

 

CNetClient* nc = CNetClient::Create();

p.m_serverIP = "11.22.33.44";

p.m_publicDomainName1 = "www.nettention.com";

p.m_publicDomainName2 = "www.nts.go.kr"; // 네 그렇습니다. 국세청입니다. -_-;;;

nc->Connect(p);

 

(C#도 가능하나 일단 생략)

 

어떻게 IPv4 literal만 갖고 접속을 할 수 있냐면... NAT64의 '주소조합 알고리즘'을 구현했기 때문입니다. 이 또한 내용이 기므로 일단은 생략 ^^

 

아무튼 위 API를 쓰는 것은 어디까지나 응급처치 방법입니다. 완전한 해결을 하려면 애플의 지시(?) 사항 "FQDN으로 서버에 접속해라"를 따라 주어야 합니다.

 

---------------------

 

논외: IPv6 주소가 쫙 퍼지면 인터넷 공유기는 사라지지 않을까?

 

IPv6 주소가 쫙 퍼지면 인터넷 공유기는 "이론상으로" 사라져도 됩니다. 인터넷 공유기 자체가 모자란 인터넷 주소 갯수를 해결하기 위한 방법 중 하나니까요. 

 

그러나, IP 주소당 가격을 매기는 인터넷 상품을 파는 업체가 IPv6라 하더라도 IP 주소를호락호락 추가 비용 없이 뿌리지는 않을 것입니다. 그렇다면 얄짤없이 인터넷 공유기를 갖다 붙이는 노력을 안할래야 안할 수 없죠. 인터넷 공유기에 강한 프라우드넷도 IPv6 세상에서 여전히 존재 필요성이 있을 것입니다.

 

-----------------------

 

즐코딩 하세요~

 

-------------------

 

[1]: 맥 기기를 포함해서 일부 클라이언트 사이드 IPv6 인터넷 공유기에서는 정상 작동합니다.

넷텐션에 아주 좋은 소식이 있어 여러분들과 공유합니다

게임 서버 엔진 분야에서는 대한민국 최초로 Sony PlayStation 4 Middleware Partnership을 체결했습니다!

앞으로는 모바일, PC 뿐만 아니라 콘솔에서도 프라우드넷을 만나실 수 있습니다. 

더욱 더 노력하고 발전하여 여러분께 꾸준한 도움이 되는 넷텐션으로 거듭나겠습니다.

프라우드넷을 쓴 게임 중 하나가 2011년에 중국에서 문제를 일으켰다는 사건이 화제가 되었던 적이 있습니다. (관련 링크) 문제의 현상은 P2P나 C/S간 UDP 통신량이 지나치게 많을 때 클라이언트-서버간 TCP 연결이 중간에 끊어져 버리는 것이었습니다. 이 문제의 근본 원인은 과도한 UDP 사용량이 불러일으킨 인터넷 블랙아웃 현상이었습니다. 이것을 해결하려면 UDP 통신량이 블랙아웃을 일으키지 않을 만큼 사용량을 낮추어야 합니다. 당시에는 그 문제를 해결하기 위한 많은 노력을 했고, 이를 해결하는 기술이 지금의 프라우드넷으로 이어지고 있습니다.

여기 두 단말기가 있습니다. 클라이언트-서버 관계일 수도 있고 클라이언트-클라이언트 즉 P2P 관계일 수도 있습니다. 두 단말기 간에는 UDP 통신과 TCP 통신이 같이 사용되고 있습니다.

두 단말기간 데이터 통신량을 증가시키겠습니다. 그러면 두 단말기 간에 있는 네트워크 장치(라우터나 방화벽 등)에는 처리량이 증가하기 시작합니다. 이때 일부 네트워크 장치들은 특정량 이상의 데이터 통신을 모두 처리하지 않고 슬슬 버리기 시작합니다. TCP는 스스로 이를 감지합니다. 그래서 송신 단말기의 내부에서는 보낼 데이터가 블러킹이 일어나는 대신 통신량이 증가하지 않습니다. (정확히 말하자면 한계선 즈음에서 오르락 내리락 합니다.) 

그러나 UDP는 그러한 감지를 할 수 없습니다. 따라서 데이터는 블러킹이 안 일어나지만 통신량이 끝없이 증가합니다. 그리고 두 단말기 간의 네트워크 장치는 지나치게 쏟아지는 UDP 패킷을 처리하지 못하고 버리기 시작하는데 이때 TCP를 위한 패킷도 덩달아 버려집니다. 이것이 Windows OS 기준으로 20초 이상 계속되면 TCP 연결이 끊어집니다.

중국의 인터넷 환경은 한국과 달리 네트워크 장치의 처리량 한계에 쉽게 부딪힙니다.

TCP는 네트워크 장치에서 패킷을 버리는 것을 감지하면 스스로 통신량을 줄인다고 했습니다. 이를 혼잡제어(congestion control)이라고 말합니다. 그렇다면 이 문제를 해결하기 위해서는 UDP 통신 또한 혼잡 제어 기능이 있으면 되겠죠. 하지만 TCP의 혼잡제어 기능은 ARQ 알고리즘에 근거하여 만들어져 있는데 이를 UDP에 그대로 적용하기에는 무리가 따릅니다. 반대 방향으로의 트래픽량이 많이 증가하는 등의 문제가 있습니다.

프라우드넷에 사용되는 UDP 용 혼잡제어 기능을 소개하겠습니다. 이는 다음과 같이 작동합니다.

1. 송신자 측에서는 일단 마음껏 데이터를 보냅니다.

2. 수신자 측에서는 받은 데이터의 패킷 유실율과 데이터 수신 속도를 측정합니다. 이를 일정 시간마다 송신자에게 회신합니다. 

3. 송신자 측에서는 회신된 데이터를 근거로 데이터 송신 속도를 제한합니다. 만약 패킷 유실이 전혀 없으면 제한 없이 보냅니다. 만약 패킷 유실율이 높아지면 송신자가 회신 준 실제 데이터 수신 속도를 감안해서 송신 속도를 제한합니다.

프라우드넷의 UDP 혼잡제어를 간단히 소개해 드렸습니다. 상기 기술은 넷텐션의 국내외 등록 특허(2014년 출원, 2015년 등록됨)입니다. 

한편, 프라우드넷의 P2P 통신에서는 UDP로 일반 메시지를 주고 받는 기능 말고도, reliable UDP 계층을 통해 TCP처럼 신뢰성 통신을 할 수 있는 기능도 따로 있습니다. 여기에는 위의 기법이 아닌, TCP와 비슷한 방법으로 혼잡 제어를 하고 있습니다.

프라우드넷의 UDP 혼잡제어 기능은 꽤 많이 검증되었지만, 아직까지도 전세계 모든 네트워크에서의 검증이 완벽하다고 자신하지는 않습니다. 더 나아지는 모습을, 앞으로도 많이 지켜봐 주세요.

넷텐션에서는 개발 프로젝트에서 소스 파일 관리를 위해 Perforce Helix를 사용하고 있습니다. Perforce는 유상 구매해야 하는 소스 컨트롤 소프트웨어입니다. 유상이니만큼 가격의 부담이 있지만 그만큼 제값을 합니다. GitHub처럼 부수적인 파일로 인해 폴더 크기가 비대해지지 않고, 파일 처리 속도도 빠릅니다.

Perforce에는 알게 모르게 깨알 같은 기능이 있는데요, 그 중에 하나가 Backout 기능입니다. Backout은 이미 submit 혹은 check in 한 것을 취소하는 기능인데요, 이미 submit 한 내역을 지우는 방식이 아니라, submit 하기 전의 상태로 다시 한번 submit을 하는 데 사용됩니다.

그런데 이 Backout 기능에는 흥미롭고 멋진 기능이 있는데요, 바로 submit을 한 이후의 다른 submit을 했던 것을 날려먹지 않으면서 특정 submit을 롤백시켜 버리는 기능입니다.

한 예를 들어 보겠습니다. 다음과 같은 함수가 있습니다.

 그런데 이 함수에 버그가 있습니다. 그래서 원인을 추적하기 위해 로그를 출력하는 루틴을 추가했습니다.

 그런데 이것을 오랫동안 submit을 안 하고 작업하니까 불안합니다. 백업을 하고 싶습니다. 그런데 기왕이면 Perforce에 submit하는 형태로 백업을 하고 싶습니다. 그래서 쿨하게(!) submit을 했습니다.

 코드를 아래와 같이 수정했습니다. 그리고 submit 했습니다.

아, 드디어 버그를 찾았습니다! 문제의 라인을 삭제했습니다. 그리고 submit 했습니다.

 그런데, 앞서 submit한 것 즉 change 25683의 임시로 넣은 코드가 있습니다. 저것은 지우고 싶네요. Change 25683의 변화 내역(diff)를 열어서 하나 하나 수정하는 방법도 있지만, 이러한 경우 Perforce의 Backout으로 한큐에 해결할 수 있습니다.

Change 25683에 우클릭 후 Backout을 선택하면 뭔가가 수정된 채 check out 됩니다. Backout 실행 후 get latest version과 Resolve를 해주는 것 잊지 마시고요.

 Backout을 실행 후 만들어진 check out 된 파일에 대해 변화 내역(diff)를 열어보면, 놀랍게도 로그 코드를 추가한 이후의 수정사항 들이 모두 유지된 채로, 딱 로그 코드만 뿅 사라져 있습니다!

 자 이제 submit 고고고. 소스를 직접 수정하지 않고도 로그 코드가 사라졌습니다.

 Perforce는 이밖에도 많은 수의 브랜치(stream)을 관리하는데도 편리하고, 과거 파일을 빨리 얻는다던지, 오래된 파일이나 다른 폴더와의 통째 비교를 빠르게 보여주는 등 여러모로 편리합니다.

 돈을 주고 시간을 살 수 있는 방법이 있는데요, 좋은 개발 소프트웨어를 도입하는 것이 그 방법 중 하나죠. 프라우드넷도 서버 개발에 대해서 시간을 돈 주고 사는 좋은 방법이기도 하죠.

ProudNet을 채택한 모바일 게임 '용사x용사'가 공식 출시 되었습니다. :)

자세한 기사 보기 ☞

http://joongang.joins.com/article/276/18094276.html?cloc=joongang%7Cext%7Cgooglenews

2015년 5월 28일 넷텐션 신제품 발표회가 있었습니다.

신제품 발표회를 기념하여 많은 기자님들에게 새로운 프라우드넷을 선보이는 자리인 기자간담회를 마련하였습니다.

또한 늦은 저녁에는 고객사분들을 모시고 프라우드넷 파티를 열어 고객사분들에게 새로운 프라우드넷을 선보였습니다.

ProudNet을 채택한 모바일 게임 '천상비 모바일'이 공식 출시되었습니다.
자세한 기사 보기

http://www.asiae.co.kr/news/view.htm?idxno=2015051513144214299

2015년 04월 20일자로 ㈜ 애니플레이와 ProudNet Mobile Platform 라이선스 계약을 체결하였습니다.

귀사의 프로젝트 성공을 위해서 지원을 아끼지 않겠습니다.