SIGPIPE가 생기는 이유가 뭔지 궁금합니다.

서버 소스를 잘 보시면 한번 accept하여 client에게 데이터를 보낸 다음 곧바로 소켓을 close 합니다.

이에 반해 클라이언트측은 한번 connection을 맺은 후에 계속해서 write/read를 수행합니다.

결국 서버측이 한번의 데이터를 보낸 후에 소켓을 close 하므로 클라이언트 입장에서는 한번의 데이터 수신만이 이루어지고, 그 후 두번째의 write 행위에서 sigpipe가 발생할 겁니다.

서버를 하나의 connection에 대해서 여러번의 request를 처리해 주도록 변경하시면 되겠습니다.

sigpipe가 나서 클라이언트가 종료되지 않도록 변경하시려면 sigpipe를 ignore 하세요.

n=Write_FD(childInfo[i].child_pipefd,"",1,connfd);

이 부분에서 unix domain socket으로 fd를 전송하도록 되어있는게 맞지요?

아시겠지만 서버의 구조를 살펴보면,

부모 프로세스가 루핑으로 계속하여 클라이언트의 connection을 accept 하고, accept 한 fd를 unix socket으로 자식 프로세스에게 전송한 후에, accept fd를 close 합니다.
자식 프로세스는 unix socket으로 전송받은 fd에서 request를 읽고, 이에 대한 response를 처리하는 방식일 겁니다.

서버를 하나의 connection에 대해서 여러번의 request를 처리할 수 있도록 변경하시려면, 부모 프로세스에서의 accepted fd를 close하는 부분을 막는것이 아니라, 자식 프로세스에서 read_fd(parent에서 fd전송받음)로 부모 프로세스로부터 받은 fd에 대해 클라이언트가 소켓을 close 할때까지 계속해서 서비스를 해주어야 합니다.

질문 처음에 보여주신 소스의 구조로 간단하게 변경해보면...

child Process(.........)\ 
{ 
... 
   close(listenfd) // 이건 fork 후 child_process 를 호출하기 전에 해주시는게 좋지 않을까요?
   read_fd(parent에서 fd전송받음)

   while( 1 ) {
      // 이 부분에 select를 넣을 수도 있겠죠?
      ...
      if( read() == 0 ) { // peer socket closed
         break;
      }
      if( write() < 0 && errno == EPIPE ) { // peer socket closed
         break;
      }
      ... 
   }
   close(연결된fd) 
... 
}

이런정도가 되지 않을까 싶습니다.

아시겠지만 TCP connection에 대해서 peer의 socket이 close 된 상태라면, 이후의 read/recv 등의 system call은 0을 리턴하며, write/send 류의 system call은 -1 을 return하고, errno가 EPIPE 입니다.
물론 이전에 SIGPIPE를 ignore 하셔야 프로세스가 종료되는것을 막을 수 있습니다.

왜 이 모델을 사용하시는지는 잘 모르겠지만, 일반적인 preforked 모델은 이런식으로 부모가 accept하여 unix domain socket으로 자식 프로세스에게 fd를 전달하는 방식이 아닙니다.

unix socket으로 process간의 fd 전달을 공부하시려는 목적이 아니라면 일반적인 preforked server 모델을 사용하시는것이 좋지 않을까요?