반응형
배경
모바일 실시간 게임을 위한 서버 아키텍처
클라이언트 <-> 서버
통신 프로토콜
socket vs http
일반적으로 성능은 소켓이 훨씬 빠르다.
다만, 접속 유지에 문제가 있다. 무선통신의 신뢰도 문제
그래서, 접속 유지를 http로 처리하는 방법론 등장
timout은 있지만, 접속 유지를 안하겠다는 것
유저간 상호작용이 비중이 문제점
결론 현프로젝트는 비적합 socket유지
서버 프로세스 분리
단일 쓰레드 사용은 사용자간 그루핑에 문제가 발생
고로, 쓰레드는 스케이러블 하게 작성 하는게 좋겠다.
클라이언트 소켓 accept
connnect
read
process
write
소켓 처리부 쓰레드 분리
-> 예전 blocking 모드로 인해, 클라이언트 접속시 쓰레드 생성 처리하였으나, non-blocking모드는 필요없다.
소켓 쓰레드 분리 및 멀티쓰레드 처리를 위해선
클라이언트 객체 버퍼에 큐를 적용 시켜야 문제가 없을터!!
현구조는
1 process 버퍼 -> 2 클라이언트 객체 버퍼 -> 3 소켓버퍼 write
클라이언트 객체에 락을 걸면, 2번과 3번은 문제가 없겠구나
근데, 변수에 락을 걸어봤자, 다른 쓰레드가 대기는 하겠지만, 변경값을 제대로 반영 안되므로 무의미함
임시방편
process에 동기화 적용 - 성능 향상엔 문제가 있겠다.
클라이언트 객체 버퍼 구조는 다행이, 생산자 소비자 패턴을 따르고 있다.(비동기 순차)
반응형