분산시스템의 커뮤니케이션

프로세서간의 커뮤니케이션(통신모델)이 필요하다.

통신모델
○ RPC(Remote Procedure Call): 원격 프로시저 호출
○ MoM(Message Oriented Middleware): 메신저
○ Streaming: Audio, Video 전송/처리
○ MC(Multi Casting)

 

Layered Protocols

 

○ OSI 7 Layer
- 통신모델의 표준으로 채택
- 동등한 레벨끼리 통신
- 실제에서는 사용하지 않음
- 다른 모델의 참고(Reference) 모델

▲ 7계층의 헤더 (식별필요)

Encapsulation
- 통신모델의 각 Layer별 데이터 구분/처리를 위해 Header 사용
- Header에서 가장 중요한 정보는 주소
- DataLink 계층은 데이터 오류검출을 위해 Trailer 사용

 

Middleware Protocols

○ Middleware Protocol은 Application Layer와 Transport Layer 사이에 위치
○ Transport Layer 이하는 O/S 영역
○ 구현은 Application Layer를 2단계로 세분화하여 상위는 Application 영역으로, 하위는 Middleware 영역으로 사용
○ Middleware의 목적(기능)
- 분산처리
- Real Time Data 처리: Streaming, Sync(동기)
- Multi Casting
- Authorization(인증) 등

 

Types of Communication

 

○ 저장방법에 따른 분류

- Persistent(영속적): 통신 시 데이터 보관을 위한 중간 Storage 존재
* Ex. MailBox (스토리지가 있어 나중에 볼 수 있음)
- Transient(임시적): 통신 시 데이터 보관을 위한 중간 Storage 없음, Buffer로 데이터 유지
* Ex. Web (bf:버퍼를뜻함)

 

○ 동기 방식에 따른 분류
- Synchronous(동기): 통신 시 데이터 교환 과정에 Block 및 Wait 존재
- Asynchronous(비동기): 통신 시 데이터 교환 과정에 Block 및 Wait 없음
- 클라이언트/서버 모델에서 서버가 어떻게 응답하는가에 따라 Block 및 Wait 시간 단축
* Request 즉시 응답 → 짧음
* Buffer 또는 Storage 보관 후 응답 → 중간
* 서비스 완료 후 응답 → 김

 

Conventional Procedure Call (RPC)

 

○ Local 내에서 Procedure 호출 시 매개변수 전달, 복귀주소 보관을 위해 Stack 사용
- Stack에 보관되는 내용: 복귀주소, Local 변수, Parameter 등

 

Client and Server Stubs (리모트인 경우에는 스택이 없기에 스텁을 이용하여 메시지를 생성한다.)
○ 클라이언트에서 서버로 Procedure 호출 시 Memory Stack을 사용할 수 없음
⇒ Stub 사용
○ Stub: 원격 Procedure 호출 시 메시지 전달 역할
- 메시지 내에는 호출할 Procedure 명, 전달
매개변수, Return 값 등을 보관
- 메시지 생성, 해독, 해제 기능 수행
○ Marshalling: 전달 데이터를 메시지로 Pack
○ Unmarshalling: 메시지를 데이터로 Unpack

 

Remote Procedure Calls

 

 

○ Synchronous, Transient 방식(Buffer 사용)

○ RPC 호출 순서

㉮ 클라이언트 Procedure가 클라이언트 Stub호출
㉯ 클라이언트 Stub은 메시지를 생성하고 O/S 호출(System Call)
㉰ 클라이언트 O/S는 메시지를 서버 O/S로 전송
㉱ 서버 O/S는 메시지를 서버 Stub으로 전달
㉲ 서버 Stub은 메시지를 해독하여 서버 Procedure 호출 및 매개변수 전달
㉳ 서버 Procedure는 처리 후 결과를 서버 Stub으로 전달
㉴ 서버 Stub은 메시지를 생성하고 O/S 호출
㉵ 서버 O/S는 클라이언트 O/S로 메시지 전송
㉶ 클라이언트 O/S는 메시지를 클라이언트 Stub으로 전달
㉷ 클라이언트 Stub은 메시지를 해독하여 클라이언트 Procedure에게 전달

Passing Value Parameters (1)

▲ RPC 예

Passing Value Parameters (2)

두 컴퓨터간 메시지 교환 시 Platform 특성 (차이점) 고려

 

▲ (a) 인텔 CPU 에서는 Little endian (낮은주소순) 을 사용한다. (b) 스파크사는 Big endian (높은주소순)을 사용한다. 참고로 Big endian은 네트워크 표준에서 쓰인다. (C) 거꾸로 된 메시지
-  parameter: 5: Integer / "JILL" 문자열

 

 

 

○ 두 컴퓨터간 메시지 교환 시 Platform 특성(차이점) 고려

- Byte Ordering: Little Endian(Intel), Big Endian(SPARC, Network 표준)
- 정수표현: 부호와 절대치, 1의 보수, 2의 보수
- 문자표현: 16bits(ASCII), 32bits(Unicode, ASCII Ext.)
- 실수표현: IEEE 754 표준 등

○ 많이 쓰이는 특성, 표기법 채택

 

 

Asynchronous RPC

 

 

○ 서비스 요청 후 완료까지 Block 및 Wait 거의 없음(최소화)

○ 서버로 메시지 전송 후 클라이언트는 다른 작업 수행

○ Two asynchronous 절차

㉮ 클라이언트 Procedure가 서버 Procedure 호출

㉯ 서버는 클라이언트에게 Accept 메시지 전송

㉰ 클라이언트 Accept 메시지 수신 후 작업 계속 수행

㉱ 서버 Procedure의 수행완료 후 결과를 Reply 메시지로 전송

㉲ 클라이언트는 현재 수행중인 작업을 Interrupt 한 후 Reply 메시지 수신

㉳ 클라이언트는 서버로 ACK 메시지 전송

 

Writing a Client and a Server

 

 

○ IDL Complier에서 프로그램 Header, Server Stub, Client Stub Code 생성
- 생성된 Code로 RPC 프로그램 작성

Binding a Client to a Server

 

 

 

서버를 등록하면 클라이언트가 서버를 찾아 바인드 할 수 있습니다.
서버 위치는 두 단계로 이루어집니다.
1. 서버의 시스템을 찾으십시오.
2. 해당 시스템에서 서버를 찾으십시오.

 

 

 

Socket= end point

Server: Bind / Listen / Accept 
Client: Connect / Send
server: Receive

TCP/IP
Client Socket ----------Server Socket  (소켓의 Endpoint 간의 통신)_

 

<-동기방식

○ 클라이언트는 Directory Server를 통해 호출할 Procedure(Endpoint)가 있는 서버 탐색
○ 서버는 DCE Daemon에 Endpoint를 등록하고클라이언트 요청에 따라 Endpoint 호출

 

MOM(Message Oriented Middleware)

○ Message Oriented Communication의 한 방식

○ 비동기 메시지 전달에 기초

○ 종류

- Persistent: MOM, MQM(Message Queuing Model)
- Transient: MPI(Message Passing Interface)

 

 

1. MPI

 

○ 분산시스템 환경에서 프로세스들 사이의 통신을 오직 메시지 송·수신으로만 구현
○ Socket 통신(프로그램) 응용
○ Transient지만 동기/비동기 통신 모두 지원
○ Primitive 중 isend(비동기), issend(동기방식)는 Reference 전송 수행
○ 원시적 Socket 기능 보완

2. MQM

 

 

 

○ Persistent 방식: 전송경로 중간에 Storage 존재
○ Loosely Coupled 형태
- Sender와 Receiver가 Decoupling 되어있음
- Sender가 전송한 메시지는 Queue(Storage) 에 저장
- Receiver는 Sender의 메시지를 사용가능한 시점에 Storage에서 가져옴

Message-Queuing Model (2) 설명
Put - 비동기
Get - 스토리지
Poll - 메시지확인
Notify - 메시지가 들어오면 도출되도록 함

 

 

 

 

General Architecture of a Message Queuing System

 

 

Figure 4-19. 큐잉레이어에서 센더측은 DB를 가지고 있다. 그 DB에 있는 네트워크 주소(TCP/IP and Port) 와 큐주소를 룩업 맵핑한다. 그리고 리시버로  보낸다. Sender와 Receiver는 동시에 켜져있을 필요가 없다. 
* 동일 Network Level인 경우(근거리) 

Figure 4-20.
- 송·수신측 Router에도 Queue 존재
- Store-and-Forward 방식 (라우터를 거칠 때 상황에 따라서, 저장 또는 포워드한다)
- 수신한 메시지는 Queue에 보관하였다가 Network가 사용 가능할 때 전송
* Wide Area : 동일한 서브넷이 있지 않기 때문에 중간 라우터를 통과하여 목적지에 가야 한다. 센더 리시버의 큐 그리고 여러 라우터의 큐를 통과하여 전달된다.

 

Message Brokers (일종의 게이트웨이의 역활)

MOM  센더와 리시버가 메시지 포멧들이 다른 경우에는 포멧들을 변환할 수 있는 메시지 브로커가 필요하다.
Figure 4-21. 중간 메시지 브로커를 통하여 이후에 목적지까지 간다.

 

IBM's WebSphere Message-Queuing System (대표적 큐잉시스템 예 IBM)

Sending Client & Receiving Client

- 네트워크 중간에 큐매니저가 존재
- 동일망 (Subnet) 내의 클라이언트와 큐매니저는 RPC 통신(동기방식)으로 전달한다. 
- 참고로 RPC는 Stub을 사용하고 역시 리시버 클라이언트도 Stub하고 마쉘링/언마쉘링을 사용한다.

Queue  Manager
- Queue Manager 사이에는 각 네트워크의 Queue 형성 (통신(비동기) 사용)
- MCA(Message Channel Agent)를 통해 원하는 지역의 Queue Manager에게 메시지 전달 (Channel에 대해서는 아래 도표 확인)
- 수신측 Queue Manager는 수신자가 이용 가능할 때 다른 Network에서 수신한 메시지 전달

▲ Figure 4-24. 메시지 채널 에이전트와 관련된 일부 속성.
- Transport type - 프로토콜
- FIFO delivery - FIFO 사용유무
- Message length - 메시지 최대 크기
- Setup retry count - 실패시 재시도 횟수
- Delivery retries - 전달 횟수

 

Message Transfer

 

 

▲ 라우팅 테이블과 별칭을 사용하는 MQ 대기열 네트워크의 일반적인 구성입니다.

QMA: Queue Manager A / QMB: Queue Manager B / QMC: Queue Manager C / QMD: Queue Manager D 
큰 직사각형 4개는 Subnet 을 의미
각 서브넷마다 Queue Manager 존재
원거리 전송 시 Queue Manager가 Relay 역할
Routing Table에 따라 전달 경로 결정 - Routing Table이 중요한 역할

 

 

Data Stream

 

스트리밍은 서비스 품질 (QOS: Quality of Service) 만족 이 중요하다

 

 

QoS 속성

- Bitrate(전송률)
- Delay: Session Setup, End to End, Variance, Jitter, RTT(왕복이동)

 

Enforcing QoS 

 

4-27. Using a  Buffer to reduce jillter
문제: Packet이 8개가 있고 해당 패킷을  클라이언트에게 넘길 경우 도착이 다르면 자꾸 끊기는 느낌을 받을 수 있다. 
Buffering-> 질터를 줄이는 방법, 충분히 패킷이 도착했을 경우 실행 (패킷도착이 불균일할 경우 응용)

4-28
Interleaving->패킷손실해결, 패킷을 비순차적 그룹으로 묶어 전송한다. 파라미터에 따라 그룹 크기 결정 / 그림처럼 4개의 패킷이 손실되더라도 실질적으로는 연속4개로 손실된것처럼 보이지 않는다. / 손실 Frame을 최소화 하여 끊김 보완 (즉 손실패킷을 곳곳으로 뿌려 티나지 않게 한다.)

 

Synchronization Mechanisms

 

Figure 4-29. Discrete & Continue
- Slide(Discrete) 데이터와 Audio, Video(continue) 데이터 간 재생 동기 형성
- 이런 경우에는 Slide (Discrete) 기준으로 동기를 맞춘다. 거기에 Audio를 입힘.
Figure 4-30. Continue & Continue
- Audio(Continue)와 Video(Continue) 데이터 간 동기 형성
- 보통 영화와 같은 예이다. Audio&Video 가 함께 들어간다. 이럴 경우에 어디에 동기기준을 둘 것인가? 
다음 그림을 보고 이해하도록 한다.

 

* Audio: 일반 초당 8KHz, CD음질 44.1KHz
* Video: 초당 30Frames(Hz)
- 시간축상 발생빈도 간격이 긴 Source를 기준으로 동기를 맞춤
* 대체로 Video가 빈도간격이 길기 때문에 (30Hz < 8KHz) 동기 기준이 됨 

동기방법: 수행하는 계층(Middleware Level 또는 Application Level)에 따라 구분

Multicast

Multicast에는 두가지방법이 있다.
- AP-Level
- Disemmation

 

Overlay Construction (Ap-level)

- Application Level에서 수행
- Physical 망 위에 Logical Tree(전송경로)를 생성하여 이에 따라 메시지 전송
- 각각의 Multicast Group마다 Multicast Tree 생성- Multicast Tree 생성에는 Dijkstra 알고리즘 사용

 

 

- Flooding 방식
메시지를 수산하면 다른 Node에 전달 (단순)
Epidemic 알고리즘이 대표적 (중앙코드네이터없이 분산적으로 빠르게 퍼트린다)
- 목표: 정보를 가장 빠르게 네트워크 내 모든 노드에게 전달
- 단점: 오버헤드가 큼
- 노드타입: 감염/미감염/감염이됐지만 전파능력이 없거나 하고싶지 않은 노드

 

 

전파모델: Anti-Entropy, 임의의 Node를 선택하여 메시지 전달

- P라는 노드가 Q라는 노드를 랜덤으로 지정
- Push: Infected Node(P)가 Susceptible Node(Q)에게 메시지전달 (자신이 감염이 되어있어야 전달) -한계: Infected가 될 수록 감염 안된 (Susceptible) 노드를 찾기 어려움
- Pull: Susceptible Node(P)가 Infected Node(Q)에서 메시지 를 가져옴 (비감염이  감염으로 부터 정보를 가져옴)
- P와 Q는 상황에 따라 Push/Pull 한다. (가장좋은 전파 모델)

 

 

 

 

○ 메시지 전파속도: O(log2n) (처음 하나의노드로 시작해서 2의배수로 진행되어감)
ex) 1-2-4-8 8개의 노드를 3번만에 모두감염

- n은 전체 Node의 개수
- Scalable함

○ 전파 중 Stop될 확률이 Rumor Spread와 유사

○ 모든 Node에게 메시지가 다 전파되지 않을 수 있음

 

 

▲ Rumor Spread 방식 ( stop 이 되더라도 0.20 (20%)를 빼고 소문을 다 듣는다)

s: 소문 못들을 확률
p: 스탑확률

 

Rumor Spread 입증된 식: s=e^(1/pstop+1)(1-s)