다시 시작하는 TIL 18일차

오늘 한일

window32 api를 사용해서 그린 좌표 개체(Object)가 전역변수이므로 이벤트 좌표개체가 중첩되는 오류가 생겼었다.

 

 

좌표를 사용하는 함수들의 구조를 바꾸는 작업이 필요하다면 해야겠지만 이보다는 현재 페이지 이동 이벤트가 일어나면 신호를 보내서 좌표개체를 Clear하는 식으로 바꿨다.

 

생각보다 많은 라인의 코드를 레거시 코드와 합쳐놔서 구조를 바꾸는건 혼자 공부하듯이 하면 되겠지만 회사에서는 일단 안전하게 돌려놓는게 맞는 것 같다. 

 

뭔가 일이 주어져서 해결은 하는데 해결하는 방식이 콩쥐가 항아리 막듯이 긴급수습만 하는 느낌이다.

 

당장 원래도 기존에 쓰던 프로세스 통신도 Pipe을 써서 해보려고 했는데 프로세스 명령어 독점현상 때문에 결국 아직 해결 못하고 파일통신으로 대체했다...... 저번주에 pipe로 받을 방법 생각만하고 결국 구현하지 못했다. 

 

엔진에서 먼저 독점중인 운영체제 명령어를 엔진보다 우선순위를 놓게 잡아서 순간적으로 제어를 가져올 순 없을까....? 란 생각으로 방식을 바꾸고싶지만 당장 파일 통신으로 안전하게 돌아가기도 하고 지금 그거 보다 급한일이 많기 때문에...... 그래도 주석을 달아놨으니 꼭 나중에 수정할 것이다.(너 때문에 오늘 리눅스 커널 책샀다)

 

또, 미러링 할 때 사용할 요청 데이터들도 일단 로컬서버에 서브 데이터 베이스 데이터를 받아와서 사용하긴 하는데 지금 ssl이 안되서 나중에 어떻게 직접적으로 메인 데이터베이스에 연결할지도 의문이다.

 

ssl 라이브러리 도대체 왜 안되는지 이유를 모르겠다.

 

dll 파일 바인딩 중간에 오류가 생기는건지 뭔지......;; 이놈의 윈도우 운영체제 너무 난해하다.....

 

ssl 문제 때문에 생기는 문제가 또 하나 있는데, http요청도 ssl없어서 일단 주먹구구식으로 프록시 소켓 서버띄운 다음 터널링 사용해서 https로 통신하는 중인데 너무 코드를 막 짜놔서 이것도 무조건 수정해야한다.  ㅋㅋㅋㅋㅋㅋㅋ 막상 내가 수정을 생각하는 방향도 안될 수 도 있기 때문에 미래의 내가 불쌍하다.

 

오늘 개발팀이 단체로 휴가나가서 혼자 일했는데 물어볼 사람 없는게 이렇게 큰일인지 몰랐다.

 

앞으로 개발자로서 먹고 살 수있을까....? 걱정이 많이 된다.

 

퇴근 후 공부

 

종료란 개념은 TCP에 존재한다. 일반적으로 연결을 끊으면 상대방이 이후에 데이터를 보냈을지도 모르는 상황에 대해 대비할 수 없어진다.

일반적인 연결 종료의 문제점

 

close 및 closesocket 함수의 기능
- 소켓의 완전 소멸을 의미한다.
- 소켓이 소멸되므로 더 이상의 입출력은 불가능
- 상대방의 상태에 상관없이 일방적인 종료의 형태를 띈다.
- 때문에 상대 호스트의 데이터 송수신이 아직 완료되지 않은 상황이라면, 문제가 발생할 수 있다.
- 이러한 문제의 대안으로 half-close 기법이 존재한다.

시스템이 주어지는 리소스는 리소스 관리를 위해 모두 반환의 과정을 거친다.

운영체제도 반환하지 않으면 관리해야되는 대상이 지속되는것이기에 불편하다.

리눅스는 소켓과 파일이 동일한 것으로 처리하기에 close로 똑같이 회수 가능하다.

바로 회수하는 것이므로 바로 일방적인 종료의 형태를 띈다. -> read ,write도 불가능해진다.

연결을 종료하는 행동을 할 경우 상대에게 EOF가 보내진다고 약속이 되어있다.

read, write가 불가능해지는 이유는 수신과 전송의 Stream을 끊어버려 입력과 출력이 가능한 통로가 모두 사라지기 때문이다.

 

이렇게 연결이 종료되면 이렇게 통로가 끊어지기 때문에 송수신이 불가능 해진다.

half-close는 전송에 대한 스트림만 끊는것으로 수신하는 길은 열어 놓는것으로 EOF 를 보낸것을 의미한다.

즉 write만 불가능하게 하고 read만 가능하게 하는 것이다.

EOF가 전달되면 상대 입장에서 종료되었구나 하고 남은 보낼데이터가 있다면 다 보내도 받아서 읽을 수 있다.

데이터를 다 보낼거 다 보냈다 -> EOF  를 의미한다.

4 handshake 하는 이유 -> 서로 할거 다하고 깔끔하게 종료하겠다.

 

Close로 소켓을 닫았을 때

close를 하는것은 이미 4 handshake가 된것이다. -> 그러면 이게 뭐야?? 라는 생각을 할 수 있는데 여기서 말하는건 read ,write 하는 데이터가 중요한게 아니라

 

우리가 생각해야될 주체는 입출력 버퍼라는 것이다.

만약 TCP 사이에 트래픽이나 전송이 불가능한 상황이 되어서 데이터를 보내는 소켓은 전송이 불가능한 상황이니 전송이 가능하게 될 때까지 계속 기다리게 된다. 
그 상황에서 연결된 호스트가 보낼데이터 다 보냈다고 4handshake 를 하게 되면 상대 소켓이 아직 보낼 데이터있으니까 기다려달라는 신호를 보내게 된다. 아직 송수신 되지 않은 송수신된 버퍼에 데이터가 남아있다면 마저 보내야하기 때문이다.

 

즉 완벽한 종료는 버퍼 관점에서 필요한 것이다. 

 

4 handshake는 버퍼에 write한 데이터의 전송을 보장하기 위해 필요한것으로 생각하면 된다.

half-close 필요한 이유 

 

즉 완벽한 4 handshake가 끝나버리면 어플리케이션에서 write가 불가능해진다. 

이는 어플리케이션에서 나중에 데이터를 더 보내야되는 상황이 되면 문제가 될 수 도 있다.

 

소켓의 Half-close

 

Half-close

 

- 종료를 원하는다는 것은, 더 이상 전송할 데이터가 존재하지 않는상황.
- 따라서 출력 스트림은 종료를 시켜도 된다.
- 다만 상대방도 종료를 원하는지 확인되지 않은 상황이므로, 출력 스트림은 종료시키지 않을 필요가 있다.
- 때문에 일반적으로 Half-close라 하면, 입력 스트림만 종료하는 것을 의미한다.
- Half-close를 가리켜 '우아한 종료'라고도 한다.


어플리케이션 프로토콜계층에서 더 이상 보낼 데이터가 있는가? 물어보는 것이 Half-close라 생각하면 된다.

int shutdown(int sock,int howto);

 

성공시 0 실패시 -1

sock = 종료할 소켓의 파일 디스크립터 전달
howto = 종료방법에 대한 정보 전달 ,

howto 인자종류 

SHUT_RD -> 입력 스트림종료

SHUT_WR -> 출력 스트림 종료

SHUT_RDWR -> 입출력 스트림 종료

close 함수가 호출 되면 상대 호스트로 EOF가 전달된다.

이는 모든 데이터의 전송이 끝났다는 의미를 갖는다.

이것이 종료 이외에 close함수를 호출하는 목적이다.

출력 스트림만 종료해도 EOF가 전달되니 close 함수의 호출을 대체하고도 상대 호스트의 종료를 기다릴 수 있다.