Update Server.hpp

Source/Server/Server.hpp

@@ -365,23 +365,24 @@ namespace IRC
          *          \li [ \ref irc_server_kqueue_udata ]
          *         
          * @page    irc_server_kqueue_udata     Technical reason for using the controlBlock of SharedPtr in the kqueue udata
-         *  ## Summary
-         *      kevent의 udata에는 해당 ClientControlBlock에 대한 SharedPtr의 controlBlock이 들어갑니다. (listensocket 제외)  
          *  ## Details
          *      kevent의 udata에 controlBlock을 넣는 기술적 이유는 다음과 같습니다.  
+         *
+         *      kevent의 이벤트가 반환되었을 때, ident 필드의 file descriptor를 통해 클라이언트 인스턴스를 찾아야 하는데  
+         *      이 탐색비용을 줄이기 위해 예약된 udata에 클라이언트의 인스턴스 주소를 넣어두고 곧바로 접근 가능하도록 합니다.  
          *     
-         *      원래 계획은 ClientControlBlock의 raw pointer를 사용하는 것이었으나,  
+         *      이를 위한 원래 계획은 ClientControlBlock의 raw pointer를 사용하는 것이었으나,  
          *      ClientControlBlock에 의존하는 리소스의 수가 증가함에 따라  
          *      메모리를 해제하는 시점이 복잡해지는 문제가 발생하여 Shared Pointer를 사용하기로 결정했습니다.  
          * 
-         *      따라서 Kevent의 udata에 들어가는 포인터 또한 Shared Pointer로 변경되어야 했는데  
-         *      Shared Pointer는 void pointer로 변환할 수 없기 때문에 직접 사용할 수 없었고,  
-         *      Shared Pointer의 controlBlock을 udata로 사용하는 위험한 선택을 했습니다.  
+         *      하지만 Shared Pointer는 void pointer로 변환할 수 없기 때문에 직접 사용할 수 없었고,  
+         *      어쩔 수 없이 Shared Pointer의 controlBlock을 udata로 사용하자는 복잡한 구현을 선택을 했습니다.  
          * 
-         *      이 선택은 udata와 직접적으로 상호작용하지 않는 다른 부분들에서 메모리 해제에 대한 걱정을 없애주고,
-         *      udata와 직접적으로 상호작용하는 코어 부분만 복잡하게 만드는 것이므로 최선의 선택이라고 생각했습니다.  
+         *      Shared pointer를 사용하지 않는 것 보다는 이렇게 라도 사용하는 것이  
+         *      전체 프로젝트에서 메모리 해제에 대한 걱정을 없애주고,  
+         *      단지 udata와 직접적으로 상호작용하는 작은 코어 부분만 복잡하게 만들기에 유리하다고 판단되었습니다.  
          * 
-         * @see     SharedPtr::GetControlBlock(), getClientFromKeventUdata()
+         * @see     Server::mhKqueue, SharedPtr::GetControlBlock(), getClientFromKeventUdata()
          */
         ///@{
         int mhKqueue;