📻 minitalk

안전한 시그널 사용을 위한 수칙

시그널 핸들러는 비동기 작업을 지원하기 때문에 데이터 레이스가 자주 발생하며, 다양한 원인과 증상이 존재한다.

시그널 핸들러는 가능한 간단하게 유지해야 한다.

문제점

리눅스 시스템은 같은 유형의 시그널이 이미 보류 중일 경우 시그널을 대기열에 넣지 않는다.

보류 시그널은 일종의 플래그 처럼 동작하며 SIGUSR1이 연속 3번 전달되었다고 가정할 때의 슈도 코드는 다음과 같다.

시그널을 처리한다.
시그널을 처리 중이므로 대기열에 SIGUSR1을 넣는다.
```
pending[SIGUSR1] = 1;
```
시그널을 처리 중이므로 대기열에 SIGUSR1을 넣는다. (누락 발생!)
```
pending[SIGUSR1] = 1; // 덮어씌워지므로 누락 발생 
```
(1)에서의 시그널 처리가 끝나 보류 중인 시그널을 가져온다.
```
pending[SIGUSR1] = 0;
```

즉, 시그널 핸들러의 수행 시간이 길어질수록 누락되는 시그널이 많아지게 된다.

해결방법

가장 좋은 해결책은 시그널은 단 한 번만 호출되도록 설계하고 단순 플래그 설정으로 끝내는 것이다.
```
void handler(int sig) { flag = sig; }
```
하지만 minitalk에서는 연속적으로 시그널을 받아야하므로 여러 방법으로 우회를 해야한다.
- [방안1] 클라이언트에서 핸들러 처리가 끝날 만큼의 시간을 대기하고 다음 시그널을 보낸다.
<aside> ⚠️ 100 글자를 전송하는데 1초가 소요되면 굉장히 느린 겁니다
- 과제에 따르면 아무리 느려도 1초 당 100개의 문자 전송 (100 baud)가 요구된다.
- 1baud가 8bit로 구성된 경우, 100 baud는 1초 당 100 * 8 비트 전송 (800bps)가 요구된다.
- 800bps 처리를 위해서는 1초 = 1000000 마이크로초 이므로,
  - 1000000 / 800 = 1250 이므로, 비트 사이의 시간은 1250 보다 작아야 한다.
- [참고] 직렬 통신에서 일반적으로 사용하는 BAUD와 비트 별 계산 표
처리 방법
- server는 별도의 sleep 없이 시그널을 대기한다.
- client는 적절한 sleep을 통해 시그널 전송 속도를 적절히 조절한다.
  - 전송 속도가 서버의 시그널 처리보다 빠른 경우, 시그널이 누락 확률이 높다.
  - 전송 속도가 비트 사이 시간보다 매우 느린 만큼 메시지 전송이 느려진다. </aside>
- [방안2] 최대한 핸들러를 짧게 작성하고 서버에서 응답 시그널을 통해 재전송을 요청한다.
<aside> 💡 직렬 통신 관련 표준 규격인 RS485에서는 충돌 감지를 위한 모드가 존재한다.

모드 설명

Echo Mode - 성공 시, 전송 데이터를 그대로 루프백한다.
- 충돌 시, 루프백이 달라지므로 데이터가 깨졌음을 알 수 있다.
- 충돌을 감지하면 랜덤한 시간만큼 대기한 후 다시 데이터를 전송한다. | | Non-Echo Mode | - 성공 시, ACK 응답을 받는다.
- 충돌 시, ACK 응답이 오지 않으므로 일정 시간 뒤에 재전송을 시도한다. ※ ACK 응답이 충돌난 경우 동일 데이터 재전송이 발생할 수 있다. |
Echo Mode의 개념을 적용한 시그널 처리 방식은 다음과 같다.
- 서버의 처리가 성공한 경우, 동일한 시그널을 응답하여 클라이언트에 성공을 알린다. (다음 시그널 전송)
- 서버의 처리가 실패한 경우, 반대의 시그널을 응답하여 클라이언트에 실패를 알린다. (동일 시그널 전송)
- 시간 내에 응답이 오지 않는 경우 타임아웃으로 처리한다. (클라이언트 종료) </aside>