많은 수의 파일 설명자와 함께 select()를 사용하는 외부 코드

Question

Linux에서 실행되며 TCP를 사용하는 푸시 기반 메시징 서비스를 구현하는 C++로 작성된 서버 프로그램이 있습니다. 푸시 방식으로 인해 더 긴 시간 동안 열어 두어야하는 많은 동시 연결 (약 1 백만 개를 계획 중)이있을 수 있습니다. 대부분의 경우 이러한 연결은 가끔씩 중단되어 유휴 상태가되며 전송은 대다수의 경우 동시에 발생합니다.

대량의 소켓을 멀티플렉싱하기 위해 epoll을 사용하고 RLIMIT_NOFILE을 수정하여 실제로 많은 양의 소켓에서 잘 작동합니다.

내 문제는 동일한 프로그램에서 다른 유형의 연결, 특히 FastCGI (FastCGI SDK의 libfcgi 사용)가 내부 파일 설명자에 select()을 사용하는 HTTP 요청을 받아들이는 것입니다. 이는 파일 설명자가 1024 (FD_SETSIZE)보다 커지면 프로그램의 epoll 부분이 1024 이하의 대부분의 fd 숫자를 사용하면 발생합니다.

가장 좋은 방법은 무엇인지 궁금합니다. 이 문제를 처리 할 수 ​​있습니다.

select()을 사용하는 외부 코드를 모두 수정하고 poll()을 대신 사용해야합니까?

내 epoll 기반 코드 (특히 accept() 호출)가 1024보다 큰 파일 설명자 만 사용하도록 유도 할 수 있습니까? 아래 내용은 select() 기반 코드입니다.

나는 FD_SETSIZE의 가치를 어떻게 든 올릴 수 있다고 생각하지만, select()이 작동하는 방식 때문에 성능이 많이 나빠질 것이라고 생각합니다. 실제 해결책이 아니라 해킹으로 생각합니다.

Answer 1

나는 자신의 파일 디스크립터를 얻을 수 있도록 이러한 것들을 자신의 프로세스로 옮기는 것이 좋습니다. 내가 제안하는 것은 단일 TCP 연결을 통해 많은 수의 TCP 연결을 멀티플렉싱하는 프로토콜을 가지고 있다는 것입니다. 서버가 개별 클라이언트가 아닌 멀티플렉서와 ​​통신합니다. 멀티플렉서는 동일한 시스템 또는 다른 시스템에서 실행될 수 있으며 수만 개의 클라이언트 연결을 처리 할 수 ​​있으며 서버에 대한 단일 연결 만 수행합니다.

큰 장점 중 하나는 서버 컴퓨터가 많은 TCP 연결 상태를 처리 할 필요가 없다는 것입니다. 패킷 삭제, 재전송, 중복 패킷, 잘못된 SYN, 느린 링크 등과 같은 인터넷 정크를 처리 할 필요가 없습니다. 각 클라이언트마다 버퍼를 보낼 필요는 없지만 클라이언트의 버퍼링을 수행 할 수있는 빠르고 깨끗한 멀티플렉서 만 사용해야합니다.

이 작업이 너무 많거나 불가능할 경우 dup2을 사용하여 파일 설명 자의 번호를 높은 번호의 설명자로 다시 지정할 수 있습니다. 멀티플렉서를 사용할 것을 강력하게 제안합니다. 처리하려는 연결 수는 단일 프로세스에서 너무 많습니다.