Content Is King?

처음으로 “Content Is King” 이란 말을 들은 것은 기술을 다루는 책 <게임 엔진 아키텍처> 에서였다.  저자 제이슨 그레고리(Jason Gregory) 는 너티 독 (Naughty Dog) 의 리드프로그래머이다.

나는 이 책을 게임 엔진을 공부하기 위해 읽었는데 안에 “Content Is King” 이라길래 조금 충격을 먹었다. 책을 다 읽고 난 후에도 계속 기억에 남아 머릿속에서 사라지지 않았다. 산책시간때에 여러번 머릿속에 나타나 맴돌았다.

결국 나는 이 말이 어떤 meme 가 아닐까 하는 생각이 들어서 이 구절을 구글링해보게 됬다. 아니나다를까 수확이 있었다.

이 말은 빌 게이츠가 1996년 1월 3일에 지은 글의 제목이라고 한다. 원문도 찾을 수 있었다:

Content is King by Bill Gates

참고로 마이크로소프트 공식 사이트에서는 이 글을 이미 지웠다.

이 글을 통해 이 구절이 무엇을 표현하고 싶었던건가, 그리고 이 말의 유래에 대해 알게 되였다. 배경을 살펴보자면 때는 인터넷 열풍이 일기 직전이였다. 구글은 창립되지도 않았고(1998), Yahoo 는 창립된지 1년밖에 안됐으며 NASDAQ IPO 하기까지 아직 3개월 전이다. 프로그래밍 언어 Java 는 출시된지 8개월밖에 안됐다.

1월 3일이였으니까 위대한 시대의 여명(黎明) 새로운 한해에 들어서며 빌 게이츠 형님은 아마도 트렌드를 사고하게 되였을 것이다. 이미 성공한 마소이고 이미 성공한 빌 게이츠였건만 새로운 시대가 다가오고있음을 확실히 느꼈을 것이다.

Continue reading

Advertisements

Skynet 의 UDP 지원

작자: cloudwu

번역: coolspeed

오랜 고민 끝에 결국 skynet (https://github.com/cloudwu/skynet) 에 기본적인 UDP 지원기능을 넣기호 했다. 대부분 경우, 특히 네트워크 게임 영역에 있어서 나는 UDP 프로토콜 사용을 반대하지만 skynet 은 이미 게임영역에만 사용되는게 아니라는 점을 고려하여 UDP 지원을 추가하는게 의미있는 일이라고 생각했다.

그나저나 최근의 피드백상으로 보면 어떤 사람은 skynet 을 이더넷 스위치 (Ethernet Switch, L2스위치) 상에 사용했고 (사용한 CPU 가 powerpc 의것이여서 Big / Small Endian 관련된 버그들을 해결하는데 도움이 됐다고 한다), 증권영역에 사용했다는 사람도 있었다. 그리고 비디오 방송영역에서 사용한다는 사람도 있었다. 그리고 아마 skynet 을 web 개발에 사용하는 사람도 있을 것이다. 간단한 테스트 결과에 의하면 성능면에서 lua 를 nginx 에 접합시켜 사용하는 것보다 못지 않았다.

현재 UDP 부분의 코드는 이미 완성되였는데 github 에서 udp 라는 브랜치에 넣었다. 멀지 않아서 마스터 브랜치에 머지할 생각이다. 나 자신은 이 방면의 니즈가 없어서 이런 니즈가 있는 친구들이 코드를 읽고 실제로 사용해주기를 바란다. 그래야 잠재한 문제점들을 찾을 수 있으니까.

이 부분의 설계와 일부 api 문서들은 wiki 에 보충해넣었다. ( https://github.com/cloudwu/skynet/wiki/Socket ) (중문)

Written in November 13, 2014
Translated in December 24, 2015

원문링크: http://blog.codingnow.com/2014/11/skynet_ae_udp_oeoe.html

Skynet 설계 설명

작자: cloudwu

번역: coolspeed

한달이란 시간에 걸쳐 드디어 skynet (https://github.com/cloudwu/skynet) 의 C 버전을 완성했다. 중간에 여러 모듈을 반복하여 리팩토링 한 결과 최종 남은 코드는 얼마 되지 않았다: 겨우 C 코드 6천여줄, 그리고 Lua 코드 천여줄이었다. 비록 일부 코드는 좀 급하게 짰지만 나 자신의 퀄리티 요구에 부합된다. 버그는 피면하기 어렵겠지만 이정도 작은 규모의 코드베이스는 충분히 명료하여 수정하기가 어렵지 않을 것이다.

Github 에 올린 이 프로젝트를 개발하는데 사용된 시간은 사실 한달도 훨씬 안된다. 나의 대부분 시간은 지난 반년 넘게 짜놓은 Erlang 버전 프레임워크와의 하위호환성과 호환 안되는 Erlang 모듈들을 포팅하는데 허비했다. 이 부분 코드들은 저희의 실 게임프로젝트와 관련 있는 것이어서 오픈하지 않았다. 또한 양이 이보다 몇배나 되는 관련코드들을 왕창 올려봤자 이 오픈소스프로젝트의 의미에 도움이 되지 않을 것이다. 프로젝트에 관심을 가지는 친구들은 그런 별로 중요하지도 않고, 많은 인터페이스들이 레거시 부담으로 추하게 설계된 구조 때문에 오히려 미궁에 빠질 것이다.

저희의 구 프로젝트와 연동시켜 보고 포팅도 다 잘 됐음이 확인된 후에 나는 또 skynet 의 일부 밑층 설계를 수정했다. 안전한 포팅을 보장하는 전제하에서 최대한 개선을 함으로써 히스토리컬 레거시를 최소한으로 걺어지도록 힘썼다. 이런 수정들은 쉽지 않았지만 의미가 있다고 생각한다. 최근 내가 자세하게 생각을 굴린 성과들이다. 오늘의 이 블로그글에서 나는 이번 픽스된 버전을 토대로 설계 설명을 좀 기록하려고 한다. 추후 찾아보기에도 좋게.


Skynet 코어는 어떤 문제를 해결하는가

나는 우리의 게임 서버가 ( 하지만 skynet 이 게임서버에만 사용될 수 있는게 아니다) 충분히 멀티코어의 파워를 이용할 수 있기를 바라며 서로 다른 비즈니스 로직들을 서로 독립적인 실행환경속에서 협동적으로 작동시키기를 원한다. 최초에 나는 이런 실행 환경이 OS 의 프로세스이기를 바랬다. 하지만 후에 발견한건데 만약 우리가 임베디드 언어를 필연적으로 사용하게 된다면, 예를 들어서 Lua, 독립적인 OS 프로세스의 의미가 크지 않을 것이다. Lua State 는 이미 충분히 양호한 샌드박스 환경을 마련해주어 서로 다른 실행환경을 격리해줄 수 있었다. 뿐만아니라 멀티스레딩 방식은 상태 공유를 통해 데이터 교환을 더욱 효율적으로 할 수 있게 해준다. 그러면서 멀티스레딩이 흔히 비평받는 단점들, 이를테면 복잡한 스레드 락, 스레드 스케쥴링 등은 밑단의 규모를 가능껏 제한하고 설계를 최대한 간소화함으로써 최소한의 범위안으로 가두어둘 수 있다. 이런 입장에서 skynet 은 최종적으로 3000 줄 안되는 C 코드로 코어층을 구현했는데 이것은 코딩 좀만 할줄 아는 C 프로그래머라면 빠른 기간내에 이해하고 유지보수 할 수 있는 규모이다.

핵심기능차원에서 skynet 은 오직 한가지 문제만 해결한다:

하나의 규약에 부합되는 C 모듈을 다이나믹 라이브러리 ( so 파일) 로부터 가동시켜 영원히 겹치지 않는 (모듈이 꺼지더라도) 하나의 숫자 id 에 바인딩하여 handle 로 사용하는 것이다. 모듈은 서비스 (Service) 라 불리고 서비스들은 서로 자유롭게 메세지를 보낼 수 있다. 모듈은 skynet 프레임워크에 하나의 callback함수를 등록하여 그것으로 자기에게 보내온 메세지를 받는다. 모듈들은 모두 하나하나의 메세지에 의해 드리븐 되고 메세지가 오지 않을 때에는 펜딩되여있으며 CPU 자원 소모가 0이도록 보장된다. 자발 실행적인 로직이 필요하다면 skynet 시스템에서 제공하는 timeout 메세지를 이용하여 일정 시간마다 트리그 시킬 수 있다.

Continue reading