[DevLog][CSAPP] 10장 시스템 수준 입출력 (10.1~10.5)

proxy-lab에서 소켓통신을 구현하기 위한 reading

10. 시스템 수준 입출력

• 입출력은 메인메모리, 터미널, 디스크와 같은 장치들 간에 메모리를 복제하는 것이다.
• C에서는 printf, scanf같은 것들이 사용자 수준 입출력을 제공한다.
• 하지만 Unix에서 사용되는 시스템 콜 수준의 입출력 (Unix I/O)을 알아야 한다.
  1. 사용자 수준 입출력은 문제가 많다. 따라서 네트워크 프로그래밍에 쓸 수 없다.
  2. Unix I/O를 이해하면 다른 시스템을 이해할 수 있다.

10.1. Unix I/O

네트워크, 디스크, 터미널을 모두 '파일'로 볼 수 있다. (파일로 모델링된다?) 네트워크를 대상으로 한 파일 입출력이 결국 통신.. 이다.

👀 Unix 파일 시스템의 종류
ext가 파일 시스템이다. 여러 버전이 있다.

👀 File Descriptor
파일을 식별하는 작은 비음수 정수값. 프로세스가 파일을 열면 커널이 이를 할당해준다. 파일이 닫으면 할당되었던 식별자가 가용 식별자 풀로 되돌아간다. 유닉스에서 식별자 0은 표준입력, 1는 표준출력, 2은 표준에러다. 파일이 열리면 커널은 프로세스마다 가지고 있는 프로세스 테이블에 식별자와 파일의 주소, 파일의 현재 위치(오프셋)를 저장한다. (식별자는 파일의 주소를 참조하는 인덱스 역할을 한다.) 따라서 오픈 가능한 파일 디스크립터의 수는 보통 제한되어있다. (내 컴퓨터에서는 1048576개)

1. Open File: 식별자 (descriptor) 라는 비음수 정수값을 반환한다.
2. Changing the current file position: 파일의 시작 주소 대비 현재 파일의 위치이다. 파일을 읽고 쓸 때 변화한다.
3. Reading and Writing files: 현재 파일 위치에서 n만큼 파일을 읽거나 쓴다.
4. Closing files: 파일 접근이 종료되면, 커널에 파일을 닫아줄 것을 요청하고 커널은 파일 식별자를 다시 가용상태로 만든다.

10.2. File

1. 일반 파일: 임의의 데이터이다. 텍스트 또는 바이너리지만 커널의 관점에서는 동질의 파일이다.
2. 디렉토리: 링크들의 배열로 구성된다. 각각의 디렉토리는 최소한 자기 자신과 자기 부모라는 두 개의 엔트리를 갖는다. (./, ../)
3. 소켓: 네트워크상의 다른 프로세스와 통신하기 위해 사용하는 파일이다.

👀 디렉토리가 링크들의 배열로 구성된다?

여기서 말하는 링크란 다른 말로 '디렉토리 엔트리'이다. 즉, 디렉토리란 디렉토리 엔트리(행)들의 배열이다. 디렉토리 엔트리에는 파일 이름 또는 디렉토리 이름, 연결된 inode 번호가 적혀져 있다. 파일을 읽고자 한다면 (예를 들어 cat 명령어로 텍스트 파일을 읽는다면) 시스템은 먼저 파일의 이름을 기준으로 해당 디렉토리 엔트리 배열에서 inode번호를 찾고, 그 주소를 참조하여 실제 데이터가 저장된 블록으로 가게 된다. 데이터는 일반적으로 4KB단위로 연속되어 저장되므로 (페이지) inode는 하나의 파일을 읽어오기 위한 다수의 데이터 블록 주소값을 계층적 구조로 가지고 있다. (Direct Block과 Indirect Block) -- 그래서 하나의 디렉토리 안에는 동일한 이름의 파일을 가질 수 없는 것이다.

👀 디렉토리의 inode에는 뭐가 있을까?
디렉토리의 inode에도 메타데이터가 저장된다. (디렉토리를 만든 시간, 이름, 등등..) inode에 저장된 블록 주소값으로 가면 디렉토리 엔트리 배열이 있다.

👀 inode의 (주소값이 아닌) 번호만으로 어떻게 읽어올 수 있을까?

이는 Unix 스타일 파일 시스템에서는 대부분 inode를 비롯한 파일의 메타데이터를 저장하는 공간의 시작주소와 사이즈가 고정되어 있기 때문에 가능하다. 파일 시스템마다 하나의 inode블록 크기는 모두 같고, 메타데이터가 저장되는 공간의 크기 (일반적으로 전체 파일시스템의 1%)도 정해져 있기 때문에 inode의 번호만으로 읽어올 수 있는 것이다. +) 파일 시스템 자체에 대한 주요 메타데이터를 저장하는 공간을 '슈퍼블록'이라고 한다.

리눅스 디렉토리 계층구조

10.3. 파일 열기와 닫기

open() & close()

int open(char* filename, int flags, mode_t mode);
int close(int fd);

파일 열기 함수는 파일 이름 filename과 열기 모드 flag, 접근 권한을 설정하는 mode를 인자로 받아 파일 식별자 file descriptor를 반환한다. 구체적으로는, 파일 이름으로 inode를 찾고, 그 inode 블록 주소를 프로세스의 File Descriptor Table에 엔트리로 생성한다.

flag와 mode인자를 설정하기 위해 비트마스크가 이용된다.

👀 umask?

명령줄에서 ls -l을 치면 파일 이름 옆에 drwx..로 된 10자리 문자를 볼 수 있다.

연습문제 10.1.

#include "csapp.c"

int main() {
  int fd1, fd2;
  umask(DEF_UMASK);

  fd1 = Open("foo.txt", O_RDONLY | O_CREAT, DEF_MODE);
  Close(fd1);

  fd2 = Open("hello.txt", O_RDONLY | O_CREAT, DEF_MODE);
  printf("fd2 = %d\n", fd2);
  Close(fd2);

  return 0;
}

fd2 = 3을 출력한다. 0, 1, 2는 표준입력, 출력, 에러를 위해 예약되어 있다.

10.4. 파일 읽기와 쓰기

read() & write()

ssize_t read(int fd, void* buf, size_t n);
ssize_t write(int fd, const void *buf, size_t n);

읽기 함수는 인자로 파일 디스크립터와 파일을 읽어올 버퍼의 포인터, 읽을 사이즈를 바이트 단위로 받아 정상적으로 읽어온 경우 읽은 바이트수를 리턴하고, 그렇지 않으면 -1을 리턴한다. 쓰기 함수는 인자로 파일 디스크립터, 파일에 쓸 내용이 담긴 버퍼의 포인터, 쓸 사이즈를 받아서 파일에 쓰고, 쓴 바이트수를 리턴한다. 비정상적으로 종료된 경우 마찬가지로 -1이다.

Short Count

요청한 것 보다 더 짧은 바이트만 읽거나 쓰는 것. 어떤 경우에 발생할까?

1. EOF를 만나면 거기까지만 읽는다. 따라서 50을 요청해도 20 후에 EOF가 있다면 20만 읽는다.
2. 터미널에서 텍스트 줄을 읽고자 할 때, 버퍼 사이즈가 내가 요청한 것보다 작으면 짧은 카운트가 발생할 수 있다.
3. 네트워크 소켓을 읽거나 쓸 때. 내부 버퍼링 제약과 긴 네트워크 지연으로 인해 짧은 카운트가 발생할 수 있다.

10.5. RIO Package

Robust I/O Package. 짧은 카운트를 자동으로 처리하는 IO패키지를 만들어보자.

1) 어플리케이션 수준의 버퍼가 없는 입력/출력 함수

ssize_t rio_readn(int fd, void* usrbuf, size_t n) {
  size_t nleft = n;
  ssize_t nread;
  char* bufp = usrbuf;

  while (nleft > 0) {
    if ((nread = read(fd, bufp, nleft)) < 0) {
      if (errno == 4) /* read가 읽어오지 못한 경우 */
        nread = 0;
      else
        return -1;
    } else if (nread == 0) /* end of file */
      break;
    nleft -= nread;
    bufp += nread;
  }
  return (n - nleft); /* 읽어온 바이트수*/
}

ssize_t rio_writen(int fd, void* usrbuf, size_t n) {
  size_t nleft = n;
  ssize_t nwritten;
  char* bufp = usrbuf;

  while (nleft > 0) {
    if ((nwritten = write(fd, bufp, nleft)) < 0) {
      if (errno == 4)
        nwritten = 0;
      else
        return -1;
    }
    nleft -= nwritten;
    bufp += nwritten;
  }
  return n;
}

2) 버퍼를 사용하는 입력 함수

typedef struct {
  int rio_fd;                 // 파일 디스크립터
  int rio_cnt;                // 현재까지 버퍼에 읽어온 바이트수
  char* rio_bufptr;           // 현재 IO위치
  char rio_buf[RIO_BUFSIZE];  // 내부버퍼
} rio_t;

// rp 초기화
void rio_readinitb(rio_t* rp, int fd) {
  rp->rio_fd = fd;               // 파일 디스크립터
  rp->rio_cnt = 0;               // 아직 읽지 못함
  rp->rio_bufptr = rp->rio_buf;  // 버퍼는 시작 지점을 가리킴
}

// size_n 은 읽어야 할 양
// buf_size 한번에 읽을 수 있는 양
ssize_t rio_read(rio_t* rp, void* usrbuf, size_t n) {
  int cnt;

  while (rp->rio_cnt <= 0) {
    rp->rio_cnt = read(rp->rio_fd, rp->rio_buf,
                       sizeof(rp->rio_buf));  // 버퍼 사이즈만큼
    if (rp->rio_cnt < 0) {
      if (errno == 4) return -1;  // 만약 errno == 4이면 반복문을 돈다

    } else if (rp->rio_cnt == 0)  // 읽은 게 없음
      return 0;
    else
      rp->rio_bufptr = rp->rio_buf;  // usrbuf로 복제를 시작해야 할 위치로 이동
  }

  cnt = n;
  if (rp->rio_cnt < n) cnt = rp->rio_cnt;  // cnt는 실제 읽어온 수
  memcpy(usrbuf, rp->rio_bufptr, cnt);
  rp->rio_bufptr += cnt;
  rp->rio_cnt -= cnt;

  return cnt;
}

ssize_t rio_readnb(rio_t* rp, void* usrbuf, size_t n) {
  size_t nleft = n;
  ssize_t nread;
  char* bufp = usrbuf;

  while (nleft > 0) {
    if ((nread = rio_read(rp, bufp, nleft)) < 0) {
      return -1;  // 4번오류 발생 시 재시작은 rio_read에서 처리

    } else if (nread == 0)
      break;
    nleft -= nread;
    bufp += nread;
  }
  return (n - nleft);
}

👀 버퍼를 사용하면 뭐가 좋은가?

read, write는 시스템 콜이므로 한번에 너무 많은 사이즈를 요청하거나, 너무 자주 요청할 시 오버헤드가 발생한다. 따라서 전체 사이즈를 적절하게 나누어서 버퍼에 옮기고, 그걸 다시 usrbuf, 즉 복제가 되어야 하는 목적지로 옮기는 것이 I/O의 효율성을 향상시킬 수 있다.

👀 오버헤드?

어떤 일을 하기 위한 간접적인 처리 비용(시간 또는 메모리)

👀 while문은 왜 있을까?

시스템 콜 read는 여러 원인들로 인해 읽어야 할 것을 '다 못 읽는' 경우가 발생한다. 이러한 read 시스템 호출의 특성을 고려해서, 만약 errno == EINTR인 경우, 즉 4번 오류인 경우에 while문이 돌아서 다시 읽어온다.

👀 4번 오류?

시스템 콜이 인터럽트 시그널에 의해 중단되었음을 나타내는 오류 코드이다. 예를 들어 키보드 키를 눌렀을 때나 네트워크 카드(NIC)에 데이터 패킷이 도착하면 인터럽트가 발생한다. 인터럽트로 인해 시스템 콜의 중단을 요청하는 시그널이 발생한 경우, 먼저 인터럽트를 처리한 후 read, write를 재시작하도록 설계할 수 있다.

👀 소켓의 식별자에 읽거나 쓰면 무슨 일이 일어날까?

파일과 같은 인터페이스를 이용하지만, 소켓은 일반 파일은 아니다. 대신, 소켓 디스크립터에 write하면 커널 메모리로 버퍼 내용이 복제된다. 커널은 소켓의 연결 상태, 프로토콜을 바탕으로 write한 내용을 패킷화, 프레임화하여 네트워크 어댑터의 버퍼로 복제한다. (Direct Memory Access를 한다.) 네트워크 어댑터에서부터 네트워크상으로 전송된다. (먼저 라우터로 전달되고, 라우터가 다시 프레임을 까서 어디다 보낼지 경로지정하고..)