listening thread in tinyNetworkLib

accept operation은 cost가 큰 operation이다.
그래서 accept만 따로 하는 listening thread를 만들곤 한다.
(Win32에서는 AcceptEx를 사용하여 더욱 더 성능 향상을 한다.)

더우기 accept에 이어서, 새로운 유저에 대한 메모리 생성 및 DB query(login관련)가 이루어지므로, 그 이후에는 더 비싼 operation들이 기다린다.
그래서,  다른 싼 operation과 합쳐서 thread pooling을 하면, 대기하는 operation들이 많아질 수 있게 된다.
그래서, listening thread를 만든다.
그러나, 그 차이가 크지 않다면, 안 만들어도 될 것 같다. 쓰레드 생성은 신중히 선택해야 할 문제이다.

"빨리 받아주고, 빨리 처리 하자"는 맞다.
하지만, "빨리 받지만, 빨리 처리 못하면?" 서비스는 악순환 일로로 가게 된다.
DDoS공격에 매우 취약한 서비스가 될 것이다.
따라서, 빨리 처리할 수 없으면 빨리 받지 않도록 설계에 고려가 되어야 한다.
처리 속도와 accept속도(?)를 측정하여 dynamic하게 조절되어야 할 것이다.
사실 그렇게까지 하는 경우는 별로 없다.

이왕 listening thread를 만들었다고 하면, 다음과 같이 하면 좋겠다.
accpeted user와 관련된 메모리들의 생성과 소멸을 모두 listening thread 한개에서 처리한다면? 다른 thread들에서는 소멸전까지 안전하게 쓸 수 있게 보장만 된다면? lock을 쓰지 않아도 thread safe하게 될 수 있다. ( 쓰더라도, 제한적일 것이고, contention이 적게 일어날 것이다. )또한, 특정 부분에서 multi thread를 위한 memory manager를 따로 만들지 않아도 될 것이다.
생성은 그렇다치고, 소멸까지 처리하려면, destroy stack(소멸처리용 데이터구조)과 같은 것을 통해서 listening thread에서 처리하는 것이 맞을 것 같다. 소멸을 위해서 destroy stack으로 post하고, listening thread에서 delete를 하게 되면, thread safe가 보장된다.

God bless me and you. ^^

도움이 되셨다면, 광고 클릭을 ㅎㅎ ^^