네트웍 서버 모델 - 분류

저번에 이어서 정리.


네트웍 서버 모델에서의 분류 기준 몇가지.
=. client 와 running context(thread 혹은 process)가 1:1 인가? n:1 인가?
=. (1:1의 경우) prespawned 방식인가? connection 요청마다 spawn 하는가?
=. (1:1의 경우) process 방식인가? thread 방식인가?
=. (n:1의 경우) multiplexing 방식을 사용하는가? async i/o를 사용하는가?


먼저 client와 running context가 1:1인 경우에 대해서 정리하면.
-. process방식, connection 요청시 fork()
-. thread 방식, connection 요청시 pthread_create()
-. process방식, preforked, child 가 accept()
-. thread 방식, prespawned, worker(?) 가 accept()
-. process방식, preforked, parent가 accept()하여 fd를 child에게 전달(unix socket)
-. thread 방식, prespawned, boss(?)가 accept()하여 fd를 worker에게 전달

1:1 의 경우에는 nonblocking socket을 사용할 필요가 없다. 각각의 child 혹은 worker가 network i/o를 하게 되므로, nonblocking의 이점을 살릴 길이 없다.
오히려 blocking socket으로 느긋하고 간단하게 코딩하는것이 나은듯 하다.


이제 client와 running context가 1:n인 경우를 보자.

-. nonblocking socket, multiplexing( level-trigger )
-. nonblocking socket, multiplexing( edge-trigger )
-. asynchronous i/o,


% level-trigger vs edge-trigger
level-triggered event notification method : '상태'를 check 하는 method
edge-triggered event notification method : '상태의 변화'를 check 하는 method

level-trigger 방식에는 select(), poll(), /dev/poll, kqueue(), epoll() 등이 있다.
edge-trigger 방식에는 epoll(), kqueue() 등이 있다.

edge-trigger 방식을 사용함에 있어서 주의할 점은
'상태의 변화'를 통지하는 방식이며, event가 여러번 발생하는 경우 여러번의 event가 queue에 쌓이는 방식이 아니기(사실 edge-trigger가 이러함을 보장하는것은 아니며, 단지 epoll과 kqueue가 그렇다는 뜻이다) 때문에 하나의 connection이 readable 한 경우 read()가 block 될 때까지 계속 읽어야만 한다.
그렇지 않으면 한 connection이 readable 함에도 불구하고 다시 통보해 주지 않으므로, starvation이 일어날 수 있다.