다시 시작하는 TIL 32일차

오늘 한일

1주일 가까이 삽질하면서 나한테 어떤걸 시킨건지 아직 파악도 못하고 그냥 시킨거를 하고 있었는데 드디어 틀이 좀 잡힌거 같다.

 

파일을 추출하고 특정 형식에 맞게 자동으로 분류되는 실행파일이나 plugin 기능을 만드는것 이었다.

 

웬만한 iot나 임베디드, 펌웨어 관련 파일 시스템은 다 linux 관련 파일 시스템이라 window에서 이거를 다 파싱해서 분류해서 핸들링하고 실행파일로 만들라는건데......

 

드디어 대표님의 의도를 파악한거 같다.

 

근데 문제는 알고나니까 솔직히 어떻게 해야될지 감도 안잡힌다.

 

wsl이나 가상 환경을 linux로 만들어서 파일 결과물을 가져오기에는 리소스가 다른 플랫폼에 비해 과하게 많이들어서 이거를 서비스로 만들기는 어려울 거같은데 이거를 가상환경에 의지 않고 네이티브로 어떻게 사용해야할까

 

애초에 우리나라에 이런거를 시도하는 기업이 있을까 싶은데 구글링을하거나 스택오버플로우에 질문을 올려도 크게 답이 나오진 않는다......

 

그리고 네이티브에서 binwalk를 사용해도 추출결과가 특정 파일은 추출되지 않는다.

 

써드파티 패키지들의 의존성 문제인거 같은데 저많은 써드파티 패키지들을 다 윈도우 형식으로 바꿔라? 이건 내 역량을 좀 벗어난거 같다.

 

흠...... 가장 그나마 간단한건 wsl로 추출하고 FTP로 받아오는건데 다들 이 방안은 별로 안끌려하는것 같다.

 

그렇다고 docker 쓰기에는 기능하나에 docker 돌리는건 문제가 있어보이고...... 기술적으로 아는 사람이 있으면 의견을 구하고 싶다.

 

퇴근 후 공부

 

표준 입출력 함수의 장점

운영체제란 하드웨어를 쉽게 사용하게 하기 위한 소프트웨어라고 생각하면 된다.

표준 입출력함수 -> ANSI 기준이다.

우리가 write같은 api는 OS 위에 API가 있고 그것을 이용해 OS와 통신한다.

ANSI는 API위에서 동작한다. ANSI = C의 여러 함수를 어떻게 동작해야된다 라고 표준화 시켜놓음

ANSI 표준에서 정해놓은거는 운영체제를 가리지 않고 다 지원해야한다.

간단하게 생각하면 Low-api는 기본적인 단위로 만들어져있다. 세밀하고 많다.

ANSI 표준은 사용자 편의적이라고 생각하면 된다.

우리는 보통 File을 컨트롤하는 방법중 하나는 api로 하거나 또는 ANSI표준으로 컨트롤하는 것이 있다.

 

여기서 말했듯이 ANSI 표준은 OS의 독립적이기 때문에 api를 사용하면 세밀한 부분을 조종할 수 있고, ANSI로 사용하면 추상화 된 느낌이 강하다.

우리가 아는 표준 입출력함수는 버퍼링한다.

이게 무슨 소리냐하면 fflush함수를 쓰는 이유는 buffer를 통해서 콘솔로 데이터를 보낼때 버퍼를 통해서 데이터가 간다.

이는 성능의 이점을 위해서 사용하는건데 한번에 버퍼에 올려놓고 데이터를 보낸다.

이는 socket을 써도 표준 입출력함수를 사용하면 버퍼링을 사용한다.

파일에다가 데이터를 보내도 버퍼링이 되고 소켓도 버퍼링이 된다.

소켓의 입출력 버퍼는 다른 네트워크과의 원활한 통신을 위해서 존재한다.

즉 입출력의 버퍼는 프로그램과 소켓의 통신을 위해서 존재하기 때문에 용도가 다른 것이다.

앞에서 배울 때 read,write함수을 사용하면 소켓의 입출력버퍼를 사용했다.
근데 여기서 입출력함수를 쓰면 그 사이 버퍼가 더 들어간다.
즉, 버퍼링의 장점을 사용할 수 있다.

표준 입출력 함수의 두 가지 장점

- 표쥰 입출력 함수는 이식성이 좋다.
- 표준 입출력 함수는 버퍼링을 통한 성능의 향상에 도움이 된다.

ANSI C 기반의 표준 입출력 함수는 모든 컴파일러에서 지원을 하기 때문에 이식성이 좋아진다.

표준 입출력 함수를 이용해서 데이터를 전송할 경우 왼쪽의 그림과 같이 소켓의 입출력 버퍼 이외의 버퍼를 통해서 버퍼링이 된다.

전에 말했듯 read 모드로 open 하고 write모드로 open이 가능하다.

open = 시스템 함수
fopen = 표준함수
File을 fopen 하면 버퍼가 만들어지는데 이때 버퍼가 하나다.
read용 버퍼가 만들어진것.

그렇다고 write하면 또 write용 버퍼가 만들어지냐? 하면 그건아니다.

즉 버퍼는 1개로 사용되고 이로 인해 데이터 충돌이 날 수 있다.

ex) write한 버퍼가 지워져야 보낼수 있다.

우리는 제대로 사용하려면 위에 사진 처럼

입력 버퍼와 출력버퍼마다 각 버퍼를 달아야한다.

표준 입출력 함수의 사용에 있어서 불편사항

- 양방향 통신이 쉽지 않다.
- 상황에 따라서 fflush 함수의 호출이 빈번히 등장할 수 있다.
- 파일 디스크립터를 FILE 구조체의 포인터로 반환된다.

fopen 함수 호출시 반환되는 File 구조체의 포인터를 대상으로 입출력을 진행할 경우, 입력과 출력이 동시에 진행되게 하는 것은 간단하지 않다. 데이터가 버퍼링 되기 때문이다.

소켓 생성시 반환되는 것은 파일 디스크립터이다. 그런데 표쥰 C 함수에서 요구하는 것은 FILE 구조체의 포인터이다. 따라서 파일 디스크립터를 FILE 구조체의 포인터로 변환해야한다.

버퍼가 존재하는데 fflush 함수가 빈번하게 등장하면 버퍼의 역할을 못하는 것이다.

데이터를 write를 하면 write가 길게 유지될때(데이터가 엄청 크거나)나 데이터가 read될때는 read만 되거나 읽을 크기가 크거나 할때 표준 입출력함수를 사용하는 것은 굉장히 매력적이다.

 

하지만 게임 같이 주고 받은 데이터가 빈도수가 높거나 실시간성이 중요하면 표준 입출력함수는 지양하는게 좋다.