Linux 네트워크 프로그래밍 실험 - 스레드 풀 구현 서버

본 실험은 15.5절에 따라 이루어졌다.원리는 매우 간단하다. 바로 epoll+다중 라인을 이용하여 고객의 요구를 처리하는 것이다.코드는git 창고에 놓았고, 아래에 내가 겪은 몇 가지 문제를 기록했다.
1. 이상 표현: 압축 측정을 할 때 서버는 -1 파일 설명자에 대한 많은 이상 닫기를 촉발합니다.나는 이 문제를 오랫동안 조사한 끝에 원래 자신이 다중 프로그래밍에 익숙하지 않아서 일어난 것임을 발견하였다.  는 모든 고객 연결에 대해 실체 클래스를 사용하여 표시합니다. 그 중에서 이 연결의 파일 설명자인connectFd도 포함됩니다.매번 처리가 끝난 후에 나는 당연히 서버 쪽에서 연결을 주동적으로 닫아야 하기 때문에 아래 코드의close가 있다.다음은 정확한 코드 형식이지만, 버그가 존재하는 코드에서, 나의connectFd=-1은close 뒤에 쓰여있으며, 버그는 여기에 묻혀 있습니다.  는 사실 제가 수동으로 요청을 계속 갱신하는 상황에서 서버가 정상적으로 작동할 수 있지만 이상하게도 압력 측정을 할 때 원래 정상적인 프로그램에 이상이 생겨서 고객 연결의 속도가 버그를 일으키는 주요 원인이라고 확신할 수 있습니다.  가 마지막으로 찾아낸 결과는 파일 묘사부호의 수정은close 뒤에 두어서는 안 된다는 것이다. 왜냐하면close가 파일 묘사부호를 사용한 후에 시스템은 다음 연결의 묘사부호를 닫힌 묘사부호와 같은 값으로 바꿀 수 있고 내 디자인에서 같은 값은 같은 실체에 접근했다는 것을 의미하기 때문이다.클라이언트의 연결이 너무 빠르면 새 연결부호는connectFd=-1 이전,close 이후에 실행됩니다. 그러면 새 연결의connectFd는 -1로 설정됩니다. 즉, 이전의 느린 라인이 다음 라인의 데이터를 수정하여 예상치 못한 오류가 발생했습니다.진정한 문제의 소재를 알게 되면 해결 방안은 자연히 매우 간단해진다.

void HttpConnection::process()
{
    accept_request();
    
    int tmp = connectFd;
    connectFd = -1;
    processed = false;
    // 
    printf("thread %u:close %d
",pthread_self() , tmp);
    if (close(tmp) != 0)
    {
        printf("HttpConnection:fd:%d errno %d:%s
", 
            tmp, errno, strerror(errno));// close ， 
    }
}

2. 이상 표현: 압력 측정을 진행할 때 일정한 수량의 연결을 보내면 모든 작업 라인이 막혀 더 이상 작동하지 않습니다.이것은 본질적으로 이전과 같지만 표현 형식이 다른 문제다.이전의 문제 해결은 나로 하여금 여러 개의 라인이 같은 고객 연결 처리 절차에 여러 번 들어가는 상황을 발견하게 했다. 유형 상황의 발생을 피하기 위해 나는 실체 클래스에processed 필드를 추가하여 이 연결이 다른 라인으로 처리되었는지 여부를 표시했다.그렇다면 작업 대기열에 넣지 않습니다.안타깝게도 지난번의 교훈을 얻지 못했습니다. 저는 프로세스d=false를 close에 다시 썼습니다. 비교적 오래된 연결이 닫혔고 새로운 연결이 신속하게 이전 연결의 fd를 점령하여 다음 처리될 작업이 되었습니다. 새로운 연결은 이미 만들어졌고 낡은 연결의 마무리 작업은 아직 완성되지 않아서 새로운 연결의processed는false로 설정되어 작업 대기열에 들어가 처리를 받을 수 없습니다.이런 상황을 여러 번 반복하면 모든 작업 라인이 임무 처리를 얻지 못해 막힌 상태에서 새로운 임무의 가입을 기다리게 된다. 마지막 결과는 시스템이 막혀서 계속할 수 없다는 것이다.
3. 신호 처리 함수는 재입력 함수로 써야 하기 때문에 printf 대신 처리된 신호 번호를 출력합니다.그러나 printf에 익숙해져서 printf에서 사용하는 습관을 write 위로 옮겼기 때문에 이런 오류로 인해 출력된 것들이 한동안 나를 곤혹스럽게 했다.write는 반드시 char에 따라 출력된다는 것을 기억해야 한다.
4. FIN 패키지를 받은 socket에 대해read 방법을 호출하고, 수신 버퍼가 비어 있으면 0을 되돌려줍니다. 이것은 흔히 말하는 연결이 닫혔음을 나타냅니다.그러나 write 방법을 처음 호출할 때 버퍼링에 문제가 없으면 올바른 쓰기 (보내기) 를 되돌려줍니다.그러나 보내는 메시지는 RST 메시지를 대단에 보낼 수 있습니다. 대단의 socket은close를 호출하여 완전히 닫혔기 때문에 보내지도 않고 데이터도 받지 않습니다.따라서 두 번째 write 방법(RST를 받은 후)을 호출하면 SIGPIPE 신호가 생성되어 프로세스가 종료됩니다.
총결: 다선정의 마무리 작업은 매우 조심해야 한다. 일단 처리를 잘못하면 후속 작업에 매우 나쁜 영향을 미칠 수 있다.
git 창고