ZeroMQ

프로토콜의 위치 Kernel VS Application

과거 => 전통적인 인터넷 프로토콜은 운영체제 내부 커널에 위치
현대 => 운영체제 상위의 어플리케이션 계층으로 주로 제공

위치에 따른 장단점?

• 성능 측면
  운영체제 내부 커널에 위치한 프로토콜의 경우 믿을 수 있고 오랜기간 개발되어 왔기 때문에 성능이 더 좋은 경우가 많다.
• 개발 및 발전 용이성 측면
  커널 내부에 위치한 프로토콜의 경우 수정을 위해서 커널을 이해해야 하기 때문에 개발 난이도가 올라가고 운영체제의 오너십을 가지고 있는 집단의 승인이 필요하다. 그렇기에 개발 및 발정 용이성의 측면에서 보았을 때 어플리케이션 계층에서 통신 프로토콜을 제공하는 방법이 더 좋다.

ZeroMQ 이해

• ZERO means
  zero brocker + zero latency + zero cost + zero administration
• 고성능 비동기 메시지 라이브러리이다.
• 분산및 동시 애플리케이션 사용을 목표로 한다.
• 브로커가 없다.
• Berkeley socket api를 일부 가져다 사용한다.
• request/reply, publish/subscriber, and others 패턴을 제공한다.

ZeroMQ 패턴

• Request-reply
  전형적인 클라이언트와 서버 구조이다. (REQ,REP,DEALER,ROUTER)
• Pub-sub
  누군가 정보를 만들어 다른 사람들에게 뿌려 버리는 공지하는 방식의 구조이다.
• Pipeline
  여러명의 일꾼들이 순차적으로 작업을 받고 전달하는 형식 앞쪽에서 하나가 일을 워커 세개에게 뿌리고 그것을 다시 싱크 하나에게 주는 구조이다. (PULL, PUSH)

ZeroMQ Sockets

• 일반 소켓 vs zeroMQ socket
  일반 소켓의 경우 1:1, n:1, 1:n 방식 제공 zeroMQ의 경우 n:n 방식까지 제공한다.
• Asynchronous ZeromMQ sockets
  물리적 연결 설정 및 해체, 재연결 및 효과적인 전달의 타이밍에 영향을 받지 않는다. 또한 피어가 메시지를 수신할 수 없는 경우 메시지가 대기열에 있을 수 있다.
• ZeroMQ socket bind & conenct
  처음부터 끝까지 유지되는 것에서 bind하고 살았다 죽었다 하는 것들에서 connect를 한다.

Request-Reply pattern

Publish-Subscribe pattern

• 단방향 데이터 분배 패턴
• 서버가 클라이언트 집합에 업데이트 적용

Publish-Subscribe with Pipeline pattern

Dealer-Router pattern

• REQ-REP pattarn의 비동기 버전
• n:1, 1:n이 섞여있을 때 사용하면 좋다.
• 클라이언트는 응답을 기다리지 않고 여러 요청을 보낼 수 있다. 서버는 새 요청을 기다리지 않고 여러 응답을 보낼 수 있다.
• 위에서 아래로 요청이 전달이 돼서 작업을 마치면 다시 아래에서 위로 올라가서 뿌려지는 작업을 하는 경우 사용한다.