버클리 소켓 셧다운 기능, 얼마나 중요합니까?

Question

배경으로 IP를 통해 제 3의 서버와 통신하는 임베디드 장치가 있습니다. 타사 서버의 코드는 변경되지 않습니다. 최근 릴리스에서는 close()를 호출하기 전에 shutdown()을 호출하기 위해 ip disconnect 함수를 변경했습니다 (이전에는 close()를 호출 했었습니다). 임베디드 장치는 특정 인터럽트가 발생하면 통신 세션을 완료하지 않고 연결을 끊습니다. 이 문제가 세션의 잘못된 지점에서 발생하면 서버는 여러 가지 이유로 고객이 받아 들일 수없는 추적 파일을 생성하고 있습니다. 이것은 shutdown이 호출 될 때만 발생하며, 서버는 이것을 보내지 못한 오류 (및 추적 파일 생성)로 처리하는 반면, 더 급한 close()는 추적 할 필요가없는 다른 끝 단절 오류로 취급합니다.

따라서 명백한 해결 방법은 종료를 호출하는 것입니다. Barnes 씨의 대답은이 question의 두 가지 기능에 대해 잘 설명하고 있지만 특정 소켓에 하나의 프로세스 만 연결되었다는 것을 알고 있다면 종료 전에 shutdown을 사용해야 할 이유가 있습니까? "갑작스러운 단절은"좋은 일이 아니다 당신의 통신 프로토콜의 일부가되었습니다 것처럼

감사합니다, 패트릭

Answer 1

그것은 나에게 소리. 클라이언트가 shutdown() 또는 close()을 사용할지 여부를 결정하기 위해 "특정 인터럽트가 발생한 후"오랫동안 실행 중이며 다른 쪽 끝이 영향을 미치면 프로토콜을 업데이트하여 "이 세션이 중단되었습니다. 메시지."

즉,이 시스템 (즉, 상호 작용하는 모든 소프트웨어)이 이러한 종류의 변화가 일어나지 않을 정도로 심하게 얼어 붙은 것처럼 들리는 것 같습니다. 문제가 실제로 무엇인지 알아내는 것이 아니라 무엇을하고 싶은지는 관리자가 무엇을 확신 할 수 없는지를 설명 한 후 관리자가 신속하고 더러운 "그냥 사용 close()"해결책을 통해 서명하도록 할 것입니다. 이것은 다른 효과가있을 수 있지만, 상황은 전에 그런 식으로 좋아 보인다. (변경 한 이후로 다른 버그가 사라진 것을 눈치 채지 못했습니까?)

잠재적으로 값 비싼 검색을 사용할지 여부를 결정하고 잠재적으로 값 비싼 (정치적으로, if 재정적으로는 안됨), 소프트웨어를 유지 관리 할 책임이있는 다른 조직의 일부 조직은 기술적 결정이 아니라 관리 의사 결정이라는 것이 기술적 인 위험에 대한 정보를 적절하게 제공해야한다는 것을 의미합니다. 는 가까운 전에 종료 를 사용하는 어떤 이유는

Answer 2

당신은 단지 하나의 프로세스가 특정 소켓에 부착 을 알고있는 경우가있다?

아니요. 밖에있는 많은 문서 들과는 반대입니다. FIN/ACK 닫기 핸드 셰이크가 아직 전송되지 않은 경우 닫기가 수행됩니다.

편집 : 그러나 종료에는 용도가 없다는 것은 아닙니다. 물론 그렇습니다. 전송을 중단하고 수신자가이를 알기를 원하지만 계속 수신하기를 원한다면 그것이 그 것이됩니다. 또 다른 용도는 거의 두 군대의 문제를 해결하고 동기화 된 닫힘을 얻는 것입니다. EOS를 읽으면 종료 및 닫기를 보내십시오. 닫기를 시작하려면 종료를 보내고 EOS까지 읽은 다음 닫습니다. 응용 프로그램 프로토콜이 올 바르면 후자의 단계에서 데이터를 읽지 않아야하며 양쪽 끝이 상당히 동시적일 것입니다.