주제 : Communication in Distributed system

결국은 서로 다른 기기들이 합심해서 일을 하기 때문에, 이들 사이에 반드시 의사소통이 이루어질 것이고,
이 때 네트워크를 알아야 한다.
이미 네트워크는 컴퓨터 네트워크에서 다뤘으니, 초간단하게 정리만 한다.

Network protocol

다양한 레벨에서 합의가 필요하다.

• 비트들을 어떻게 해석할 것인가
• 메시지의 시작과 끝을 어떻게 구분할 것인가
• 메시지가 잘못되었는지 어떻게 구분할 것인가

등등 결국엔 빛으로 오고가기 때문에, 이를 해석하기 위해선 서로의 약속이 철저하게 지켜져야 하는 것이다.

OSI는 요즘 안쓴다.

APP
Transport : TCP, UDP (connection-oriented/ connectionless)
Network : IP (보장은 안됨, 라우터 버퍼 차면 다 버리기 때문에)
Link

레이어를 쓴다 요즘은.

Layered protocol

• 레이어 하나만 바뀌어도, 인터페이스만 동일하면 다른 레이어에 영향을 안준다.
  ex. 회사 간 커뮤니케이션에서, 사장은 비서에게, 비서가 다른 회사의 비서에게, 그 비서가 사장에게 전달.
  비서는 우편 서비스(아래 레이어)를 쓰다가, 전화로 바꿨다. 사장은 알빠노?

OSI 7계층

• Physical : 0,1 보내기 / 몇 볼트 이상을 1로 볼 것이냐? 1초에 몇 비트 보낼거냐? 등
• Data Link : 비트들이 에러가 있는지 / 프레임의 헤더의 체크섬으로, 내용에 에러가 없는지 확인
• Network : IP, 목적지(IP)까지 라우팅 해줌
• Trasport : 최족 목적지인 프로세스, Port를 통해 전달해줌
  - 패킷별로 seq#를 붙여 순서대로 리오더링해 처리할 수 있다.
• Session, Presentation, APP

---

Middleware protocol

1. 일반적인 미들웨어 프로토콜

• App이긴한데, 논리적으로는 Transport와 App 레이어 사이에 위치
• 미들웨어 없이 App끼리 TCP,UDP 써도 가능은 한데, 부족한 부분이 많음.
• 앱에게 어떤 서비스를 제공해줄 것인가에 따라
  - 일반적인 미들웨어 서비스
  -커뮤니케이션 특화 서비스
  
• 예시 :
  -Authentiction service
  -Authorization service
  -Commit protocols : DB의 Atomic을 위해 (10개 요청했는데 4개되었을 경우 롤백)
  -Distributed locking protocols : 공유 리소스에 요청할 때 락을 통해 이용하게 끔
  

2. 커뮤니케이션 특화 미들웨어 프로토콜

• 하이레벨 커뮤니케이션 서비스 제공
• ex. RPC
• ex. Real-time data 동기화
• ex. 멀티캐스트 서비스 (하나의 메시지 보냈는데 여러 목적지로 쫙)
  - vs 유니캐스트 서비스 (TCP,UDP 같이 1:1)
  

3. 커뮤니케이션의 타입

• Persistent vs Transient
• Sync vs Async
• Discrete vs Streaming

Persistent vs Transient

Persistent : 받는 쪽이 실행중이 아니더라도 저장을 했다가 전해주겠다.
- ex. E-mail
Transient : TCP,UDP 처럼 실행중이여야만 전달됨.

Async vs Sync

Async : 메시지 보내고 다른 task 계속 실행
Sync : 보내면 응답을 기다리고, 응답이 와야 다른 일이 가능

Three synchronization points

1. 클라이언트의 미들웨어 : 내가 잘 보내줄게
2. 서버의 미들웨어 : 잘 받았어, 위 App으로 올려줄게
3. 클라의 앱 : 실제 응답 왔음

실제 커뮤니케이션에서는 위 타입들을 섞어서

• Persistent + async
  - Many message-queing system
• Transient + sync
  - 일반적인 경우들
  -RPC