ACE가 많이 알려지면서 수천개의 네트워크 동시 접속을 관리해야만 하는 서비스를 실행하는 방법에 대한 많은 질문을 봐왔습니다. 대부분의 네트워크 서비스들이 ACE Reactor 프레임워크를 사용하여 네트워크 연결을 다중수신 및 디스패칭하기 때문에, 항상 핸들 수용한계 및 처리성능이 고려사항과 한계점 판단 조건이 되어왔습니다.

각각의 플렛폼마다 동시에 열수 있는 화일(또는 핸들)의 개수를 제한하고 있긴하지만, 각각의 ACE Reactor에서 어떤 다중수신 구조를 사용하는가 여부는 종종 어플리케이션이 동시에 수용할 수 있는 핸들의 최대 개수를 알아내는데 중요한 요소로 생각되고 있습니다.

• WaitForMultipleObjects(). 윈도우즈에서만 사용가능하며, ACE_WFMO_Reactor로 구현되어있습니다. 이 시스템 호출은 한번 호출할때마다 64개의 핸들 제한을 가지고 있습니다. ACE는 내부적으로 2개를 사용하기 때문에 개발자는 62개의 핸들만 사용가능합니다.
• select(). (윈도우즈를 포함한) 대부분의 플렛폼에서 사용가능. select()는 ACE_Select_Reactor와 ACE_TP_Reactor로 구현되어있습니다. select()에서 사용가능한 핸들의 개수는 플렛폼에 따라 다양합니다.
• /dev/poll 또는 epoll. epoll은 리눅스 커널 2.6 이상에서 사용가능하며, /dev/poll 은 솔라리스와 HP-UX에서 사용가능합니다. 이 장치들은 모두 ACE_Dev_Poll_Reactor에 구현되어있습니다. 이들은 특별한 한계 개수가 정해져있지 않습니다. (epoll은 대략 10000개까지도 테스트한 자료가 존재합니다)
  
  

With the variety of limits and facilities available, how do you choose a way to enable your application to serve thousands of connections simultaneously? 윈도우즈 어플리케이션은 핸들제한을 극복하기위해 Reactor 프레임워크 대신 Proactor 프레임워크를 선택하는 것도 좋습니다. (내부적으로 유명한 Completion Port 장치를 사용합니다) Proactor는 여러 UNIX/리눅스 플렛폼에서도 사용가능하긴 하지만, 내장된 AIO 기능의 품질과 완성도가 상업용 어플리케이션에서 사용하기에 충분하지 않습니다. 그러므로 여기에서는 Reactor만을 다루도록 하겠습니다.

윈도우즈에서 다수의 접속을 처리하는데 있어서 Proactor 프레임워크가 더 나은 선택이긴 하지만, Reactor 프레임워크는 친숙함과 쉬운 이식성때문에 윈도우즈에서도 자주 거론됩니다. 기본적인 선택사항은 두가지가 있습니다.

1. ACE_WFMO_Reactor : 위에서 언급했듯이 62개의 핸들제한이 있습니다. 다수의 연결을 제어하는데는 알맞지 않습니다. (간단한 P2P 클라이언트 어플리케이션 제작에는 무리가 없을듯) 윈도우즈 플렛폼에서 기본으로 설정되어있습니다.
2. ACE_Select_Reactor (그리고 그 사촌, ACE_TP_Reactor) : select()에 기반하고 있습니다. 윈도우즈의 select() 구현은 특별히 핸들수가 제한되어있지 않습니다. 하지만 윈도우즈에서 구현된 fd_set 의 내부 형태로 인해, 다른 플렛폼에서 처럼 핸들 집합을 검색하는 부분을 최적화하기가 매우 어렵습니다. 그러므로 핸들제한은 피할 수 있지만 특정 어플리케이션에서 너무 많은 부하가 걸리는지는 스스로 테스트해볼 필요가 있습니다. 만약 많은 부하가 걸린다면 여러분은 Proactor 프레임워크로 변경하여야합니다.
   
   

select()는 오늘날 인기있는 플렛폼이라면 거의 필수적으로 탑재되어있으므로, 다중수신장치로서 첫번째 선택으로 결정하기 마련입니다. 하지만 select()에는 두가지 문제점이 있습니다.

1. 핸들 제한 : select()의 사용가능한 핸들 개수는 제한되어있으며, 동일한 제한을 두는 플렛폼은 거의 없습니다. 게다가 제한을 알려주는 방식은 플렛폼마다 모두 다릅니다.
2. 성능 문제 : select()는 최대 핸들 갯수 과부하가 발생했을때 상당히 안좋은 성능을 가진다는 것으로 유명합니다. 몇몇 상황에서 select()의 핸들 사용가능검사와 어플리케이션의 사용가능 핸들집합을 검사하는 작업때문에 CPU 자원이 엄청나게 소모될 수 있습니다.
   
   

In recent years, some UNIX platforms began offering a more efficient demultiplexer that scales to many thousands of handles much better than select(). 대부분은 /dev/poll이라고 이름 붙여진 가상 장치에 기초하고 있습니다. 어플리케이션은 관심있는 핸들을 /dev/poll과 관련한 시스템 호출을 사용하여 등록하고, 현재 사용가능한 핸들 모두를 검토할 필요없이 핸들 사용여부 통지를 받을 수 있습니다. 그러므로 운영체계와 어플리케이션 모두 보다 효과적으로 처리가 가능하며 select()에서의 핸들제한도 피할 수 있습니다. 최신 리눅스 커널(2.6 이상)은 epoll이라는 새로운 기능을 제공하며, 이는 /dev/poll과 매우 비슷한 기능과 시스템 호출 집합을 포함하지만, 프로그램하기에 더 쉽고 보다 융통성있는 것으로 알려져있습니다.

끝내주네요! 이것들을 어떻게 사용할 수 있을까요?! 이런 이유로 ACE는 플렛폼의 구분없이 /dev/poll 또는 epoll을 이용할 수 있도록 하기위해서 ACE_Dev_Poll_Reactor 구현을 제공하고 있습니다. (물론 윈도우즈에서는 사용할 수 없습니다.) 이것을 기본 reactor 구현과 교체하려면, 단지 인스턴스 하나를 생성하고 이를 새로운 ACE_Reactor 인스턴스로 설정하기만 하면 됩니다. CNP2권과 APG 모두 새로운 reactor를 설정하는 예를 담고 있습니다.

하지만 알아둘 것이 있습니다. ACE_Dev_Poll_Reactor는 ACE 5.4에 추가되었지만 적합성이 제한되어있는 이유로 아직 "실험단계"로 분류되어있습니다. 하지만, Riverace와 다른 ACE 사용자들이 ACE 5.5에서 ACE_Dev_Poll_Reactor를 개선하는데 (특히 리눅스의 epoll에 대한 부분을 중점적으로) 협력하고 있습니다. 이는 아주 조금 개선되었지만, 다른 reactor 구현과 같이 광범위하게 사용가능할 만큼 만들려면 몇가지 추가작업이 아직 필요합니다. 다른 여러 개발들이 끝나면 이 reactor 구현을 끝내고 이것을 추가할 수 있을 것입니다.