강사님 파일입출력(Callback함수)와 관련하여 질문 드립니다.

불가능한 것은 아니지만 적절하지는 않습니다. 비동기 요구를 OS에 요청할 경우 입/출력에 사용되는 메모리 공간에 대해 OS는 락을 겁니다. 따라서 자동변수의 메모리 주소를 전달할 경우 스택 메모리 공간에 락이 걸릴 수 있습니다. 그리고 무엇보다 스택의 크기는 스레드 당 1MB가 기본 입니다. 그런데 파일 입/출력의 단위는 경우에 따라 1MB를 넘길 수도 있습니다. 이렇게 되면 당연히 스택 메모리가 모두 소진되어 프로그램이 비정상 종료될 것입니다. 참고하시기 바랍니다. 😄

하트비트 시 서버에서의 연결 종료

서버가 하트비트를 요구하는 경우도 있지만 보통의 경우는 클라이언트가 일정 주기로 보냅니다. 서버에서는 클라이언트로부터 하트비트를 포함해 일정 주기로 데이터가 오지 않으면 연결이 끊긴 것으로 판단하기도 합니다. 하트비트는 그 자체로 부하이므로 가급적 최소화 하는 것이 바람직하기 때문입니다. 그리고 마치 Java에서 가비지 콜렉팅을 하듯 각 세션의 마지막 통신 기록을 검사해서 기준 시간 이상 아무런 통신이 없었다면 연결이 사실상 끊긴 것으로 판단하는 방법이 병행됩니다. 다 이런 구조를 갖는 것은 아니지만 보편적인 대응방법으로 참고하시면 되겠습니다. 😄

break와 중첩 Loop 예제

네, 맞습니다. 더 자세한 내용은 이 영상을 참고하시기 바랍니다. 😄 https://youtu.be/ec7O0lFaTS4?si=wWwQst_2XPceSyMT

17강. TCP 통신 장애 관련 질문드립니다.

네, 그런 오류를 보정 받은 후 정상적으로 수신하게 됩니다. 그러나 간혹 끝내 보정이 불가능할 정도로 장애가 심각하다면 TCP 연결 자체가 비정상 종료 됩니다. 그러나 경우에 따라서는 연결이 끊긴 경우 자체를 인지 못할 수 있습니다. 가령 상대 서버가 정전 등의 이유로 물리적으로 종료된다면 이를 클라이언트가 인지하지는 못합니다. 이 때문에 계속 서버와 TCP 연결을 유지하고 있다고 판단 할 수 있습니다. 반대로 클라이언트가 그렇게 된다면 TCP 연결이 지속되고 있다고 서버는 판단합니다. 이런 이유로 연결이라는 말은 어떻게 보면 주관적인 착각에 불과한 것입니다. 참고하시기 바랍니다. 😄

게이트웨이와 라우터

다른 것입니다. 게이트웨이는 '역할' 입니다. 보통 라우터나 인터넷 공유기가 게이트웨이 역할을 수행합니다. 이런 이유로 통상적으로 게이트웨이는 라우터를 지칭하는 것으로 생각합니다. 서브넷 마스크가 24비트(255.255.255.0)인 경우 호스트 ID는 256개가 있습니다. 그 중에서 0번, 255번 두 가지는 사용할 수 있는 ID가 아닙니다. 그래서 2를 빼고 사용할 수 있는 주소 개수는 254개가 됩니다. 참고하시기 바랍니다. 😄