다시 시작하는 TIL 29일차

오늘 한일 

현재 2일 넘게 삽질 중......

 

과연 linux의 파일 시스템을 window에서 어떻게 사용할까.....

 

rust된 오픈소스를 봐서 직접설치하고 실행해도 core 라이브러리를 찾을수 없다고 한다.

 

rustup add '현재 사용할 os 일련번호' 느낌으로 설정을 해줘도 인식을 못한다.

 

일단 이 오픈소스를 쓰기는 글른거 같고..... 그냥 FAT를 강제로 실행시켜서 파일만 받아와서 읽게하는 오픈소스를 찾아서 기능을 붙여야되나 싶다.

 

회사를 오면 뭔가 맨날 깨닫고 코딩을 잘해지고 그럴줄 알았는데 뭔가 게속 해매기만 하는 기분이다.

 

코딩을 잘해지는건 결국 내가 계속 퇴근하고도 코딩을 해야되는건가 싶다.

 

요즘 더 강해진 생각인데 일찍 코딩을 시작한 사람은 정말 엄청난 메리트를 가지고 가는거구나 싶다.

 

퇴근 후 공부

 

TCP상에서 데이터를 주고 받을 떄 긴급 메시지를 보낼 수 있다.

TCP에서 긴급하다고 확인안하고 보내버리면 주고 받는 순서가 깨진다.

이는 TCP의 원칙에서 어긋난다. 그래서 MSG_OOB(긴급 메시지)를 보내도 순서를 지켜야하는데 예시를  응급환자가 병원에 도착했을때라고 생각하면된다.

병원이 host고 환자가 데이터면 MSG_OOB는 긴급환자가 병원에 도착하면 처리를 빠르게 해줘야한다.

데이터를 보내는건 빠르게 하는건 아니고 도착했을때 처리를 독촉하는 느낌으로 받아들이면 된다.

OOB를 보냈다는건 메시지에 실어서 보냈다.

그러면 host는 빨리 진행하라고 데이터를 확인한다.

막상 host에서 이거를 어떻게 처리해줄지는 우리가 또 처리해줘야한다.

read, write함수를 이용해서는 특성 부여를 못했으나 send, recv는 특성을 부여하는것이 가능하다.

ssize_t send(int sockfd, const void p_buf, sizeof_t nbytes, int flags);

성공 시 전송된 바이트 수, 실패 시 -1 반환

sockfd : 데이터 전송 대상과의 연결을 의미하는 소켓의 파일 디스크립터
buf : 전송할 데이터를 저장하고 있는 버퍼의 주소 값 전달.
nbytes : 전송할 바이트 수 전달.
flags: 데이터 전송 시 적용할 다양한 옵션 정보 전달.

ssize_t recv(int sockfd, void p_buf, size_t nbytes, int flags);

성공 시 수신한 바이트 수(EOF = 0) 실패시 -1

sockfd : 데이터 수신 대상과의 연결을 의미하는 소켓의 파일 디스크립터 전달
buf : 수신된 데이터를 저장할 버퍼의 주소값 전달
nbytes : 수신할 수 있는 최대 바이트 수 전달.
flags : 데이터 수신 시 적용할 다양한 옵션 정보 전달


옵션 정보 : 

MFS_OOB : 긴급 데이터의 전송을 위한 옵션 = send ,recv 가능
MSG_PEEK : 입력버퍼에 수신된 데이터의 존재유무 확인을 위한 옵션 = recv 가능
MSG_DONTOUTE : 데이터 전송과정에서 라우팅 테이블을 참조하지 않을 것을 요구하는 옵션 , 따라서 로컬 네트워크상에서 목적지를 찾을 때 사용되는 옵션 = send 가능

MSG_DONTWAIT : 입출력 함수 호출과정에서 블로킹 되지 않을 것을 요구하기 위한 옵션, 즉 논 블로킹IO의 요구에 사용되는 옵션 = send, recv 가능 
MSG_WAITALL : 요청 바이트 수에 해당하는 데이터가 전부 수신될 때까지, 호출된 함수가 반환되는 것을 막기 위한 옵션 = recv 가능

데이터의 전송에 사용되는 옵션정보이다.

옵션 정보는 | 연산자를 이용해서 둘 이상을 동시에 지정 가능하다.
그러나 옵션의 종류와 지원여부는 운영체제에 따라서 차이가 있다.

 

긴급 호출이 일어나면 운영체제가 인식을 하고 Process에게 알려준다.

이때 전달하는 방식은 시그널로 알려준다.

해당 메시지를 버퍼에 담아서 보냈기 때문에 그 메시지를 읽었을때만 시그널이 발생하냐? -> 이건 아니다

운영체제한테 시그널로 올려놨기 때문에 해당 버퍼(메시지)를 읽으면 시그널을 파악하는건 따로 체크한다.

그래서 뭐가 더 먼저 호출될지는 모름


그러면 다음과 같은 생각을 할 수 있다.

MSG_OOP 메시지 라고 해서 더 빨리 전송 되지않는다.
긴급으로 보낸 메시지의 양에 상관없이 1바이트만 반환된다. -> 신호로서 알려주는 역할이기 떄문에 1바이트만 보여준다.


urgent mode의 동작원리

길이값을 넣으면 특정 데이터가 들어가고 그 데이터가 들어간 길이만큼

Urgent 모드에 들어가면 아웃풋 버퍼의 urgent 메시지 다음 주소값이 TCP헤더에 urgent 포인터로 등록되고 URG 비트가 활성화 된다. 

그러면 확인할 때 포인터를 가르키고 거기 바로 앞에 데이터를 반환한다. = 1바이트만