ACE [ Adaptive Communication Environment ]

출처 : http://kimsk99.springnote.com/pages/273521?print=1
ACE

ACE는 Adaptive Communication Environment의 약자로 OS 독립적인 네트워크 환경을 구축해주는 일종의 framework이다.

요즘 자주 나오는 네트워크 관련 패턴인 Proactor Pattern이 바로 ACE로부터 나온 것으로 알고 있다.

ACE 홈페이지

 

구조

 

특징

ACE는 위의 그림에서 보는 것 처럼 OS 독립적인 시스템 레이어를 제공한다.

모든 OS API는 C++로 wrapping되어 제공된다.

ACE 코드를 보면 간단한 함수도 모두 Wrapper를 통해서 사용하도록 되어 있다.

 

전송 버퍼 관리

네트워크 엔진을 만들게 되면 가장 문제가 되는 부분이 전송 데이터를 위한 버퍼 관리이다.

각 layer마다 서로다른 버퍼를 쓰게 되면 메모리 복사로 인해서 성능 저하가 발생한다.

이런 문제를 피하기 위해서 ACE에서는 MSG단위로 효율적인 버퍼 관리를 제공하고 있다.

특히 긴 데이터 전송을 위해서 MSG에 버퍼가 Linked list형태로 구성될 수 있는 특징이 있다.

또한 같은 데이터를 여러 peer에 보내야 할 경우에 대한 효율성 증대를 위해서 하나의 버퍼로 여러 MSG를 만들 수 있는 기능도 제공한다.

이것은 버퍼 자체에 reference counter를 붙여서 구현하고 있다.

이 구조(RefCnt)는 내가 이번에 짠 구조와 유사한데 역시 사람의 생각이란 모두 비슷한 것 같다.

 

Reactor/Proactor을 통한 상위 인터페이스 제공

Reactor와 Proactor이라는 굉장히 상위 레벨의 MSG 처리 인터페이스를 제공한다.

두 모델 모두 threading과 결합해서 굉장히 강력한 서버를 만들 수 있도록 되어 있다.

특히 Proactor의 경우에는 Win32의 IOCP나 Linux의 epoll로 구현되어 뛰어난 성능을 보여준다고 한다.

 

단점

너무 많은 OS wrapping으로 인한 성능 저하

추상화를 통해서 OS독립적인 코드를 짤 수 있다는 것은 좋은 일이다.

그러나 이로 인한 성능 저하는 어쩔 수가 없는 것 같다.

모든 OS API를 직접 콜 할 수가 없고 모두 wrapper함수를 통해서만 콜할 수 있다.

물론 상당수의 wrapper는 inline으로 되어 있지만 그래도 일정 부분의 성능 감소는 감수할 수 밖에 없다.

 

너무 많은 클래스 들

어떻게 보면 실재 구현에서는 거의 쓰이지 않을 것 같은 Process나 Memory map까지도 wrapping해 두었다.

그리고 최상위 인터페이스 뿐 아니라 모든 인터페이스가 노출된 구조라서 처음에 배우는 과정이 어려울 수 밖에 없다.

최근에 ACE측에서도 이런 점을 인식하고 최소한의 셋으로 구성된 minimum 버전을 만들 예정이라고 한다.

이런 시도를 통해서 가벼운 ACE가 나오면 좀더 좋을 것이다.

 

평가

너무 복잡한 인터페이스를 가지고 있기는 하지만 빠른 개발과 안정성에 대한 요구를 충분히 만족시켜줄 수 있는 프레임워크라고 생각한다.

성능 면에 있어서도 어느정도 이상을 충분히 보장하리라 본다.

게임을 개발할 때도 충분히 사용할 수 있는 강력한 프레임워크가 될 수 있을 것이다.

다음번에는 이거 써서 만들어 볼까?