서버 accept 시점.

서버 모델 중.

다음과 같이 작성할 수 있습니다.

1. listen(listenfd) 
    newfd = accept(listenfd)
    thread_create(func,newfd)
    func(newfd)
          :
      일처리(클라이언트는 thread와 통신한다.)

2. listen(listenfd)
    fork()
    자식: newfd = accept(listenfd)
    자식이 일처리(클라이언트는 자식프로세스와 통신한다.) 

3. litend(listenfd)
    fork()
    자식: thread_create(func)
    func() {
        newfd = accept(listenfd)
        일처리(클라이언트는 thread와 통신한다.)
    }

위 모델을 가만히 보면.

서버는 listen을 통해 3-way handshake을 완료한뒤

위의 3가지 방법을 통해 서로 다른 시점에 accept를 호출하여

클라이언트와 통신할 newfd를 생성하고 있습니다.

그렇다면 이렇게 accept를 다른 시점에서 호출하는 이유가 있을

거 같습니다.

유추해 보면..

서버 메인은 단순 listen 만을 고려하고 나머지 일은 자식 프로세스

든 thread든 그것들에게 일을 맡긴다. 정도로 생각할 수 있을거 같

습니다.

그런데... 위 모델중 3번째 방법 같은 경우 listen -> fork -> thread

-> accept 같은 식으로 client가 서버에 연결하기 까지 꾀 많은 과정을

거처야 합니다. 이러한 방법이 어떤 장점이 있을까요?

또한 1, 2번 모델 같은 경우도 각각의 장.단점에 대해 무엇이 있을까요?

경험으로 통한 각각의 장단점에 대해 설명해 주실 수 있으신가요?

그럼.. 즐거운 하루 되세요... ^_____^;;