중계서버 설계 관련

[kbu1564]

설계 인원 : @formfoxk @kbu1564

중계서버를 보다 효율적으로 유지보수가 뛰어나도록 하기 위해 Class를 재설계 한다.
기본뼈대를 들어내고 다시 새로이 구성하여 제작을 들어간다.

코딩하면서 몇번 구성이 바뀔듯 하다.

위 이미지는 현재 중계서버 1차 UML 설계도

[kbu1564]

이전 클래스 다이어그램을 바꾼 2차 UML Diagram

Device 별로 Send 함수의 루틴이 다를 예정 이므로 Device 를 상속받은 Phone과 Client(PC)의 두 클래스 정의
하지만 현재 ServerHandler 의 역할과 처리 가능 범위가 상당히 애매한 상태 또한 구지 저렇게 나눠서 Abstract 형식으로 된걸 재정의 해서 사용해야햐는지도 의문인 상태

차라리 ServerHandler의 Method 들을 Server 안에 집어 넣고 사용자는 서버 생성시 Server 를 상속하여 정의한뒤 사용한다면? 또한 ThreadPool 을 만들어서 여러가지 패킷들이 Queue 형식의 버퍼로 부터 하나씩 꺼내져서 사용되어 진다면 더 좋을듯. 그렇게 된다면 구조도 바뀌어야 하고 동기화 처리도 들어가야되고.....

각 메시지 처리를 위한 Class 들과 Packet 들을 커멘드 패턴으로 설계 해볼까 생각중...

[yunheur]

To @kbu1564

진하게 표시한 부분의 아키텍처로 변경할 경우, UML 다이어그램이 변경 되어야 할 것 같아요.

그리고, 불필요한 클레스와 함수들이 많고, 현재 UML과 변경될 UML의 설계가 혼합되어, 지금 UML이 무엇을 뜻하는지 알기 모호해요.

[kbu1564]

@formfoxk
UML 공부하면서 작성하고 설계 하느라 다소 처음과 두번째가 상당히 잘못된 것이라는것을 인지 - 3차 설계 변경중
기호 표기법도 잘못된 부분이 다소 보임...

[kbu1564]

중계서버 SW 아키텍쳐 설명

아래 3차 설계 한 UML 설계도와 현재 내가 생각한 중계 서버 아키텍쳐를 아래 설명함

중계 서버 3차 설계 UML

중계 서버 동작 흐름

서버 구현시 Server 클래스의 method 들을 이용하여 서버를 생성하도록 되어있으며 각각의 클라이언트들은 하나의 장치로 구분되어 스마트폰 1대의 소켓에 1대이상의 PC 소켓이 대응되어 Group 클래스로 Wrapping 처리됨

이렇게 생성된 Group 객체들을 배열형식으로 Server 클래스에서 가지고 있게 됨

각각의 클라이언트에서 전송되는 데이터들은 ThreadPool 로 관리되고 있는 Thread 들에 의해 수신처리 되며 데이터 수신시 수신된 패킷이 어떠한 속성의 타입인지 PacketParser 클래스를 통해 decode 작업을 수행하여 PacketExecuteQueue 에 push 되어 Server.executeLoop() 함수의 내부에서 해당 작업큐로 부터 하나씩 꺼내어 꺼내진 Packet 객체의 execute() 함수에 의해 해당 패킷의 루틴을 수행하게 됨

각각의 클라이언트의 비정상 종료를 위해 특정 주기적으로 Heartbeat 를 날리는 Thread 를 하나 별도로 둠

각각의 ReceiveThread 의 경우 일정한 수만큼의 클라이언트들을 관리함

구현시 예상 문제점

• epoll_wait 함수의 처리에 따른 소켓별 이벤트 처리 부분

[kbu1564]

문제점을 보안한 4차 설계

변경된 부분

3차 설계 당시 여러 ReceiveThread 에서 데이터를 수신하여 PacketExecuteQueue 에 저장하는 방식에서
단 하나의 main thread 에서 데이터를 수신하여 PacketExecuteQueue에 저장하는 방식으로 변경하였으며
이렇게 저장된 큐에서 ExecuteThread 들이 각각 작업을 하나씩 할당받아 처리하도록 설계 변경

[yunheur]

To @kbu1564

수정이 필요하다고 생각하는 부분

1. Server에서 PingThread와 ExecuteThread Uml 표기는 하지 않아도 될 것 같습니다.
   이유 : ThreadPool을 통해 사용하기 때문
2. Server와 PacketExecuteQueue와의 UML표기는 하지 않아도 될 것 같습니다.
   이유 : ThreadPool에 있는 ExecuteThread에서 사용하는 것이기 때문

[kbu1564]

@formfoxk

1. ? 정확한 이유 설명 부탁함
2. 해당 부분의 경우 Server 클래스에서 receiveLoop 함수를 통해 여러 디바이스 장치로 부터 수신받은 패킷들을 PacketExecuteQueue 에 쌓아놓도록 되어있음 따라서 위와 같이 그림을 표시함

[kbu1564]

@formfoxk @kbu1564

• Android app에서 관리하고자 하는 사용자 컴퓨터의 MAC 주소를 설정하여 해당 MAC 주소의 컴퓨터를 제어하도록 한다.

[yunheur]

문제점을 보안한 5차 설계

[kbu1564]

중계 서버 7차 수정된 설계

기존의 Group 형식을 제거하고 자식 클라이언트 쪽의 MAC 주소를 기준으로 하여 hash_map 으로 그룹화하여 관리함
부모클라이언트 : 스마트폰
자식클라이언트 : PC