source:http://javaservice.net/~java/bbs/read.cgi?m=resource&b=qna2&c=r_p&n=1089088514&p=1&s=t#1089088514
제목 : Re: Non-Blocking I/O로 구현한 채팅 아키텍쳐에 관해
글쓴이: 전재성(jaesjun)
2004/07/06 13:35:14 조회수:13 줄수:33
JDK 1.3까지는 기존의 소켓 프로그래밍시 select() 와 같은 I/O Event를 감지할 수 있는
기능이 없었습니다. 그래서 setSoTimeout()나 하나의 클라이언트당 하나의 Thread를
두어 Blocking의 문제를 해결하였지요..
JDK 1.4부터 nio 패키지에 Non-Blocking I/O의 개념이 추가되어 하나의 클라이언트당
하나의 Thread를 생성했을 때 드는 Overhead를 줄일 수 있게 되었습니다.
nio의 핵심은 Blocking I/O의 개념과 이를 해결하기 위한 Selector 관련 클래스,
Selector를 통해 실제 I/O를 담당할 Channel, Buffer관련된 클래스를 이해하는 것입니다.
관련 개념이나 클래스들은 API Reference를 찾아보심이 제일 빠를것 같고,
채팅구현시 서버 아키텍쳐는 큰 범주에서는 아래와 같을 것입니다.
클라이언트 접속 -> Accept Selector -> Read/Write Selector ->
Dispatch I/O readiness Channel to Worker Thread -> Worker Thread( Processing I/O )
Acceptor Selector, Read/Write Selector는 하나의 Thread로 통합할 수도 있고
각각의 Thread로 분리할 수 있습니다.
Worker Thread는 Thread Pooling 형태로 미리 만들어 놓고 I/O Event가 감지된
채널들을 Dispatch해주면 되겠지요.
채팅 관려된 User, Room 클래스 들은 Selector를 관리할 필요 없이 등록된 채널을
가지고 있고 Read -> Parsing -> Write 형태의 로직처리만 해주면 됩니다.
귓속말, 쪽지 같은 경우는 Selector나 Thread와는 별개의 문제입니다.
-
결국 이렇게 앞에서 selector하나 두고 worker thread pool 만들어서 뒤에서 일처리하는게 일반적인 대용량 네트웍 처리 서버 모델인가 싶군요. (뭐야 내가 추측했던 대로잖아.. 실망.)
근데 Reactor는 뭐하는 패턴이었더라.. (이런 돌머리 ㅠㅠ)
여기랑 상관있을거 같은데..
읽은지 1년도 안된책에서 본건데도.. 흑.
이젠 아예 보는대로 잊어버리는군요..
