티스토리 블로그 서비스가 계속 될지 알 수 없어서 블로그 이전 하기로 했습니다.

지금까지 이 블로그에 올린 글은 그대로 두고 새로운 글부터 새로운 블로그에서 시작합니다.


새 블로그는 https://jacking75.github.io/  입니다



RSS 관련

저는 Feedly 서비스를 사용 중인데 이 서비스에서는 rss 추가에서 https://jacking75.github.io/ 주소를 넣으면 추가가 됩니다.


https://jacking75.github.io/feed.xml 이 주소를 사용하면 rss 추가 됩니다.

저작자 표시
신고
by 흥배 2016.12.16 12:16

깃허브에 지킬로를 사용하면 블로그를 만들 수 있다.

그런데 그냥하려면 컴퓨터에 루비도 설치해야 하고, 카테고리나, tag 등의 기능이 없어서 바로 사용하기에는 좀 불편하다가.


그러나 jekyll-now( https://github.com/barryclark/jekyll-now )를 이용하면 루비 설치도 필요 없이 블로그에 필요 기능을 쉽게 구현할 수 있다.


jekyll-now를 사용하여 블로그를 만드는 방법은 아래의 글을 추천한다(영어 잘 모르면 구글 번역해서 보면된다)

http://digitaldrummerj.me/blogging-on-github-part-1-Getting-Started/



그리고 한량넷( http://www.halryang.net/ ) 블로그도 참고 하기 바란다.


제일 간단한 방법은 한량넷 블로그를 fork 한 후 자신에 맞게 수정하는 방법이다.

https://github.com/Halryang/halryang.github.io



지킬 세팅하기

http://kaora.co.kr/jekyll/2016/01/06/jekyll-setting/

저작자 표시
신고
by 흥배 2016.12.14 08:00

번역 글로 2016/10월 기준. 이후 바뀔 수 있음

 

APNS GCM에서 Push 통지를 할 때의 제한 정리

 

APNS

iOS8 미만의 경우 페이 로드 데이터의 상한은 256 바이트까지.

iOS8의 경우 페이 로드 데이터의 상한은 2K 바이트까지.

iOS9 이후의 경우 페이 로드 데이터의 상한은 4K 바이트까지.

1회 통신에서 전 패킷이 5000~7000 바이트를 넘으면 APNS 에서 절단된다?(확실하지 않음)

패킷의 제한은 상당히 완만하지만 너무 빠른 리퀘스트는 에러가 되므로 1리퀘스트당 10~50밀리 초 정도의 간격을 두는 것이 좋을 듯(확실하지 않음)

 

4번째와 5번째 정보는 비공식이고 상반되는 것이기 때문에 결국은 스스로 확인할 수밖에 없다고 생각하는데 "적어도 초당 9000 메시지는 송신할 수 있다" 라고 Apple의 공식 문서에 있는 것 같아서 일단 너무 한꺼번에 대용량의 메시지를 발송하지 않고 가끔 sleep 처리를 넣으면 괜찮지 않을까 생각한다.

 

 

GCM

페이 로드 데이터의 상한은 4096 바이트까지.

멀티 캐스트 전송의 경우 최대 1000 단말까지.

 

모두 공식 정보이므로 확실함.

 

 

 

어떻게 해야 할까?

위의 제한이 있으므로 멀티 OS 대응의 경우 서버 애플리케이션은 Push 메시지는 140 문자 이내(Push에서 그렇게 긴 메시지 보내지는 않을 것 ⇒ Twitter와 같은 글자 수만 있으면 충분하지! 라는 생각으로)로 하고,

수 천대 이상에 한번에 보내고 싶다면 GCM에 맞추어 1000건씩 분할,

동시에 APNS를 배려하여 각 처리 사이에서 0.1초 정도 간격을 주고,

APNS GCM에 요청하면 거의 괜찮지 않을까 생각한다.

 

 


출처: http://qiita.com/itosho/items/f4ec3495c2d2782c5359

저작자 표시
신고
by 흥배 2016.12.12 08:00

KGC 2016 강연 문서이다.

아래 링크에 가면 문서와 예제 코드가 있다.

https://github.com/jacking75/kgc2016_SuperSocket



실시간 네트워킹 게임 서버를 만든다면 C#을 프로그래밍 언어로 사용하기를 추천하며, 

C#을 사용한다면 SuperSocket을 추천한다.

저작자 표시
신고
by 흥배 2016.12.08 06:00

현재 NHN NEXT에서 게임 겸임 교수로 일하게 되어 이전에 비해 시간 여유가 생겨서 일에 방해가 되지 않는 한도 내에서

 

1. C++, C#, 게임서버 개발에 대한 강의

2. PC, Mobile 게임 서버 개발 컨설팅

과 관련된 일을 의뢰 받습니다

 

관심 있는 분들은 jacking75 @ gmail . com 으로 연락 주시기 바랍니다.


저에 대한 설명은 https://github.com/jacking75/choiHeungbae 를 참고하시면 좋을 것 같습니다

 

 

ps) 이 글에 댓글로 질문은 하지 말아주세요. 질문은 메일로 부탁합니다

저작자 표시
신고
by 흥배 2016.12.02 18:26

이유는 유효한 메일 주소 등의 정보가 풀리퀘스트에는 빠져 있거나 diff가 비 실용적이라고 한다

Git의 풀리퀘스트 기능과 GitHub의 호스팅 서비스에 대해서는 호의적으로 평가하고 있지만 GitHub의 풀리퀘스트에 대해서는 종합적으로 봐서는 부족해서 쓸만하지 못하다고 평가했다.

Linus씨는 이것을 GitHub에게 전했지만 GitHub쪽에서는 잡지 못했다고 한다.

 


출처: https://github.com/torvalds/linux/pull/17

저작자 표시
신고
by 흥배 2016.12.02 10:36

MongoDB_id 값은(데이터를 넣을 때 MongoDB가 넣어주는 값의 상위 문자는 만들어질 때의 unixtime16진수 표현이다.

그래서 _id 값의 상위 문자를 추출해서 datetime으로 변환하면 시간을 알 수 있다.

 

string mongo_id = "57b3ce6269d7d0098ef3b603";

 

string hexString = mongo_id.Substring(0, 8);

int num = Int32.Parse(hexString, System.Globalization.NumberStyles.HexNumber);

 

Console.WriteLine(num);

Console.WriteLine(DateTimeOffset.FromUnixTimeSeconds(num).ToLocalTime());




저작자 표시
신고
by 흥배 2016.11.30 08:00

IOCP에 관한 자료는 네이버를 검색해도 꽤 많이 나온다(IOCP가 최신 기술은 아니니...)

그런데 대부분 IOCP를 사용한 예제는 쉽게 찾기 힘들다.

그래서 설명을 보고 실제 구현을 해볼 때 좀 망막할 수 있다.


IOCP를 처음 구현해보는데 시작이 잘 안되는 경우 아래의 프로젝트를 기반으로 해보기 추천한다.

이것은 넥스트에서 게임서버 수업 때 사용한 자료이다.


fixme_degiyamIOCP

https://github.com/jacking75/fixme_degiyamIOCP


'온라인 서버 제작자 모임'에 degiyam 이라는 닉네임의 개발자분이 오래 전에 공개한 것이다.

컨텐츠 구현 부분이 거의 없고, 클라이언트도 간단하게 있어서 분석하고 테스트 하기 좋다.

또 윈도우 서비스 모드와 콘솔 모드를 동시에 지원하는 프로그램 개발할 때 참고하기도 좋다.


fixme_MyFirstGameServer

https://github.com/jacking75/fixme_MyFirstGameServer


본인이 오래 전에 첫 서버 프로그래머로 처음으로 만든 온라인 게임 서버 이다.

처음 개발한 것이라서 지금 보면 문제점이 많다.

실제 게임 컨텐츠가 구현되어 있고, 코드가 C 언어스러워서 위의 프로젝트 보다 분석하기 쉽지 않을 것이다.



온라인 상으로 질문에 대한 답변을 하기에는 내 시간이 너무 소요 될 것 같아서 받지 않는다. 

꼭 물어보고 싶다면 판교 테크노밸리까지 오기 바란다^^;;;



저작자 표시
신고
by 흥배 2016.11.28 08:00

한국 온라인 게임 개발에서 PC에서 모바일로 넘어가면서 온라인 게임 서버 개발에 큰 변화가 있었다.

 

모바일 시대 이전에는 ‘Windows OS + MS SQL Server + IOCP(비동기 네트워크) + C++’ 조합이 거의 표준 기술이었다

그러나 지금은 비실시간 통신을 아직은 많이 사용하고, C++ 이외의 다른 언어를 사용하는 등 다양성이 크게 생겼다.

 

그리고 모바일 게임 개발 특성 상 개발 기간이 최대한 빨라야 좋고, PC에 비해 네트워크 환경이 좋지 않아서 이전에 비해 상용 네트워크 엔진을 구매해서 서버를 개발하는 경우가 꽤 늘었다.

 

상용 네트워크 엔진은 일단 유료이기도 해서 처음 구매한다면 꽤 고민이 될 것이다.

나는 아직 상용 네트워크 엔진을 사용한 적이 없지만 내가 만약 구매한다면 나는 기술 지원 이 가장 잘 되는 것을 사고 싶다.

 


완벽이라는 것은 있을 수 없고, 혹은 엔진에는 문제가 없지만 사용자의 실수로 잘 못 사용할 수도 있다. 

이 때 엔진 판매사에 문의를 하면 빠른 피드백으로 문제를 해결해줘야 안정적으로 게임 개발과 게임 서비스를 할 수 있다.

 

내가 구매한 엔진이 다른 프로젝트에서는 문제 없이 잘 사용되었지만 하필 재수 없게 내가 사용할 때 버그가 나온 경우 엔진 개발사가 빨리 이것을 고쳐주지 않는다면 개발이 정체되고 앞으로 또 이런 문제가 발생했을 때를 생각하면 무척 불안해질 것이다.

 

네트워크 엔진을 사기 전 가능하면 엔진 개발사가 어느 정도의 기술 지원을 할 수 있는지 꼭 확인 하는 것이 좋다

엄청나게 성능이 좋고, 가격이 아주 싸더라도 기술 지원을 제대로 받을 수 없는 회사라면 자체 개발해서 사용하는 것 보다 더 많은 위험도를 감수해야 하고 많은 시간을 소비할 수 있다.

(특히 네트워크 엔진의 경우 소스 코드도 대부분 주지 않으므로 고치려고 해도 고칠 수도 없다)

저작자 표시
신고
by 흥배 2016.11.25 08:00

Microsoft Connect(); // 2016  행사에서 발표된 것이다.


성능 평가를 보면 성능 부분에서는 문제가 없다고 봐도 될 것 같다.

ASP.NET Core는 지금도 계속 성능 향상 부분에 작업을 하고 있어서 앞으로도 더 기대가 된다.



출처: https://connectevent.microsoft.com/


저작자 표시
신고
by 흥배 2016.11.23 08:00