[info] 선구자들의 피드백

[yechoi42]

• read fds, write fds에 등록하는 건 cgi 자식프로세스의 fd
• 클라이언트는 최대한 끊지 말기. 끊었다 재 연결하면 휴지기간 때문에 fd가 엄청 늘어나버림.
• 클라이언트 닫는 조건은 eof
• 받은 메세지를 std::string으로 저장해도 되지만, substr 이나 + 연산 사용하면 부하 엄청남
• 대신에 인덱스를 기억해뒀다가, 원하는 사이즈만큼 읽기/쓰기
• read 한번했을 때 request message가 반개일 수도 있고 열개일 수도 있음. 자르고 남은 건 저장해두기.
  -> 저희는 버퍼를 사용하지 않습니다.
• Robustness? 언젠간 필요하게 될 개념이다...

[yechoi42]

견고함의 원칙(robustness principle)은 소프트웨어를 위한 일반적인 설계 지침이다.

당신이 하는 일은 엄하게, 남의 것을 받아들일 때는 너그럽게. (종종 “보내는 것은 엄하게, 받는 것은 너그럽게”로도 일컬어진다.)
이 원칙은 전송 제어 프로토콜(TCP)의 초기 명세를 쓴 존 포스텔(Jon Postel)의 이름을 따, 포스텔의 법칙(Postel's law)이라는 이름으로도 알려져 있다.[1]

TCP 구현은 견고함의 원칙을 따라야 한다: 당신이 하는 일은 엄하게, 남의 것을 받아들일 때는 너그럽게.
명령이나 자료를 다른 컴퓨터(또는 같은 컴퓨터의 다른 프로그램)에 보내는 코드는 명세를 철저하게 따르되, 입력을 받는 코드는 의미가 분명한 한은 명세를 따르지 않는 입력까지도 받아들여야 한다.

RFC 1122(1989년)는 포스텔의 원칙을 보충하여, 프로그래머가 “가능한 최악의 효과를 나도록 고안된 패킷을 전송하는 악의적인 존재들로 네트워크가 채워져 있다고 간주”[2]하길 권했다. 프로토콜은 모르는 코드를 포함한 메시지도 받아들이는 식으로 나중 버전에서 기존의 필드에 새로운 코드가 추가될 것을 감안해야 한다. 프로그래머는 “프로토콜에 명세되어 있긴 하나 불분명한 기능들”은 보내는 메시지에 포함하지 말아야 한다. 메시지를 받는 쪽에서 미처 구현하지 못한 기능일 수 있다. 또, “명세대로 동작하지 않는 다른 호스트와도 잘 돌아가게만 할 것이 아니라, 그런 호스트들이 공유 통신 설비에 악영향을 초래하는 것도 제한하는 식으로 협조”[3]하도록 코드를 설계해야 한다.