[풀스택] ZMQ Pattern

 

 

 

ZMQ Request-Reply pattern

• ‘Hello World’ client/server example
  • Client sends “Hello” to the server
  • Server replies with “World”
  • 1:1 TCP echo 서버와 유사
• Synchronous REQ-REP socket
  • 어플리케이션은 동기, 통신에 대한 부분은 알아서 비동기로 처리됨
  • Client issues send() and then recv(), in a loop
  • 클라이언트가 선택한 패턴 - 리퀘스트 패턴 / 서버는 리플라이 패턴
  • Doing any other sequence (e.g., sending two messages in a row) will result in a return code of -1 from the send or recv call

 

 

 

request - reply

 

 

 

< server >

• basic class -> import zmq
• 일종의 ZMQ를 처리하기 위한 객체 생성
• 소켓 타입은 REP (응답)
• 서버를 바인드 .bind 시킨다 -> 서버(socket)이 살아나고, 바인드 시킴 (tcp와 유사)
• 1초 쉬는 함수를 쓰려고 import time 

 

 

< client >

• client는 request pattern 
  context.socket(zmq.REQ)
• 서버의 bind에 상응하는 connect
• app 이 동기라는 이유
  -> 동기 방식으로 서버의 값을 기다리고, 출력하고, 반복 

 

 

 

• Autonomous 1:N REQ-REP socket
  • You could throw thousands of clients at this server, all at once, and it would continue to work happily and quickly
  • tcp server - multi-thread -> 백그라운드로 구현 일일이 해야 함
  • Example:
    • Single server : lec-05-prg-01-req-rep-basic-server.py (NO modification)
    • Three clients : lec-05-prg-02-req-rep-basic-client.py
    • 서버를 수정하지 않고, 클라이언트 3개 띄워서 붙여버린다.
    • 통신에 대한 비동기 처리, 멀티 스레드 기능을 기본적으로 제공한다. 
    • 개발자가 구현해야 했던 로직을 알아서 처리한 것!

 

 

 

ZMQ Publish-Subscribe pattern

• Connects a set of publishers to a set of subscribers
• One-way data distribution pattern
• Server pushes updates to a set of clients
• stable한 애를 서버(bind)로 잡는다 - 해당 패턴에서는 PUB 
• 하나의 메세지를 보낼 때, 여러 명의 subscriber에게 보내는 것

 

 

 

publish - subscribe pattern https://zguide.zeromq.org/docs/chapter5/

 

 

 

•  PUB-SUB weather broadcasting example
  • Server pushes out weather updates consisting of a zip code, temperature, and relative humidit
  • Client listens to the stream of updates and grabs anything to do with a specified zip code
  • zip_filter at setsockopt_string (line number 21)
  • Client must set a subscription using setsockopt() and SUBSCRIBE, as in line number 21
  • 날씨 서버는 주기적으로 전 지역의 정보를 보낸다
  • 스마트폰 (클라이언트) 본인의 위치 정보를 기반으로, 선택적으로 정보를 받는다

 

 

 

< server >

• 클라이언트의 응답을 받는 코드 X
• 메세지를 전달하기만 하면 됨
• 개발자가 처리할 필요가 없다 -> zmp에게 보낼 정보만 주면, 알아서 처리함
• socket type - PUB, bind() -> server 역할
• 우편 번호, 온도, 습도를 랜덤으로 생성하여 보내는 상황

 

 

< client > 

• SUB 역할을 맡는다
• 사용자가 항목을 주면, sys.argv -> zip_filter에 담김 
• zip_filter를 통해 원하는 정보만 받을 수 있다.

 

 

 

• PUB-SUB socket characteristics
  • PUB-SUB socket pair is asynchronous
  • PUB-SUB socket is unidirectional
  • 어플리케이션 짜는 사람 입장에서, 내용만 이해하고 코드는 구현할 필요 없이 zmp 쓰면 됨
  • 서버는 알아서 비동기로 처리됨
  • Client does recv(), in a loop (or once if that’s all it needs).
    Trying to send a message to a SUB socket will cause an error
  • server - send - PUB / client - receive - SUB (바뀌면 에러 발생)
  • Similarly, the service does send() as often as it needs to, but must not do recv() on a PUB socket.

 

 

 

Publish-Subscribe with Pipeline pattern

• Pipeline pattern
  • 병렬 처리 -> 파이프라인이라는 용어 사용 
  • Connects nodes in a fan-out/fan-in pattern that can have multiple steps and loops
  • Parallel task distribution and collection pattern
  • 분산 처리에서 이러한 방식으로 짜는 경우 많다.  
    • push 밀어내는 것
      pull 당기는 것
    • 작업을 3개의 일꾼에게 뿌린 후, 하나로 모으기 
      빅데이터 처리 등등 분산 처리에서 많이 활용

 

 

 

pipeline pattern

 

 

 

•  PUB/SUB with PUSH/PULL example
  • Server 
    • PUB & PULL 기능
    • 구동시 PUBlish 및 PULL 서버 기능을 활성화 함
    • Client들이 주기적으로 보고하는 상태 정보를 PULL 한 후, 다시 모든 Client들에 PUBlish 함
  •  Client
    • SUB & PUSH 기능
    • 주기적으로 자신의 상태 정보를 Server에 PUSH 함
    • Server가 PUBlish한 (본인 포함) 전체 Client들의 상태를 SUBscribe 기능을 통해서 수신함
    • state를 주고 받으나, 채팅과 다를 바가 없다

  

 

 

https://zguide.zeromq.org/docs/chapter5/

 

• 오래 버티는 애를 서버로 위치시킨다
• 살았다 죽었다, 동적인 애 -> 클라이언트
• 클라이언트가 서버에게 state를 보냄
  ex) 본인이 로그인 상태라는 것을 서버에게 알림
  PC 버전 카톡 or 네이트온 등등 -> 상태 정보: active or inactive 
  한 시간 동안 알람을 받지 않겠다 등등 이러한 상태를 담아서 보내는 것
• 클라이언트가 본인의 정보가 바뀌었을 경우 -> state update
• 이렇게 받은 상태를, 서버가 sub 애들한테 보내주는 것
  누구누구는 지금 액티브하지 않아 (자리 비움 상태야)

 

 

 

ZMQ Dealer-Router pattern

•  Asynchronous version of REQ-REP pattern
• N-to-1 architecture where various clients talk to a single server, and do this asynchronously
• 1-to-N use case where one server talks asynchronously to multiple workers
• N개 클라이언트의 요청을 1개의 서버가 받으니, 누구에게 돌려주어야 하는지 

 

 

 

Asynchronous version of REQ-REP pattern

 

 

 

• Asynchronous version of REQ-REP pattern -> 나도 이 문구가 가장 잘 이해된다 ! 
  • Clients connect to the server and send requests
  • For each request, the server sends 0 or more replies
  • Clients can send multiple requests without waiting for a reply -> async 
  • Servers can send multiple replies without waiting for new requests -> async 

 

 

 

Asynchronous Client/Server example

 

 

 

Asynchronous Client/Server example

• 클라이언트들의 요청을 받는 관문, load balancer -> 라우터
• 이 서버들 중에 누가 좀 더 stable하냐 -> 누가 서버냐가 아니다, 모두 다 서버임! 
• 뒤에 있는 일꾼들한테 전달
  일 업무 분배 하고, 끝나면 취합
  원래 응답한 애들한테 다시 전달

 

• 필요할 때 필요한 만큼 
  worker를 늘리거나 줄이는 행위 -> 개발자의 몫
• multi-threading
• 워커를 띄우는 기능은 직접 해야 함
• zmq가 해주는 건 통신 기능에 국한한 것!
• application 영역의 조작은 개발자의 몫 

 

 

 

Dealer-Router pattern with Multi-thread Client

• Separe send and recv features in a client
• Enhanced version of lec-05-prg-10-dealer-router- async-client.py
• Recv feature in a client is impelled as a thread
• 리시브 핸들러를 thread 화 
  zmq -> 클라이언트, 서버, 워커 -> 워커를 조정 가능
  클라이언트들도 fulled flex로 동작할 수 있게 만든 것

 

 

 

Dirty P2P example

• Self-Healing P2P network with brute-force discovery
• Just for learning purpose (too heavy)
• Connect to every IP address in the room
• If your network segment is 192.168.55.x, for instance, you do this:
  • 서버 없이 P2P가 구현되면 어떻게 될까?
  • 현재 네트워크에 있는 모든 컴퓨터를 다 붙이는 것 
    255 * 255 개 connection을 만드는 것 -> 각 노트북이 1: 255
  • 내가 보내고 싶을 때, 메세지를 255회 전송
    소켓을 내 프로그램 혼자 255개 엶 
    운영체제가 255개의 소켓을 동시다발적으로 연다? -> 메모리 or 프로세스 부하, 단순 무식한 방법
  • WebRTC를 활용한 p2p 통신 -> 웹 브라우저 위에서 돌아가는 API 
  • 유무선 공유기를 넘어가는 애들은 답이 없는 것 
    -> 유무선 공유기를 넘어가려면 트래픽이 너무 많아서, 네트워크 망가짐
  • 24시간 살아있는 서버는 없지만, 
    255개의 peer node중 하나가 총대 매고, 잠시 서버 기능을 맡는다. 
    -> 조정하는 애가 하나 뜸 -> 이 노드의 지휘 하에 통신이 이루어짐

 

 

 

• 활성화 된 서버 역할을 하는 애가 있는지 check
• 비콘 함수를 스레드로 띄워서 병렬 시작
• IP주소와 아이디를 통해 등록

 

• 살아있는 서버가 있어요? 
  살아나서 1번부터 255 까지, 현재 이 네트워크 안에, 서버 기능을 수행하고 있는 애(비콘)가 있는지 찾는것
  비콘이 1초 단위로 정보를 뿌리니깐, 커넥션하고 비콘 보내니? -> 2초 기다리고 아니면 연결 끊고
  만약에 비콘 정보가 오면 -> 본인이 서버 역할을 할 필요가 X
  비콘 역할이 아무도 없다면 -> 서버가 없다 -> 본인이 서버가 되어야 한다.  

 

• 누군가 총대를 매는 경우
  서버 기능을 띄우는 데, 필수적인 기능을 몇 개 만듦
• beacon - 주기적으로 주고 받는 정보를 비콘이라고 부른다. 
  256개의 노드 중, 누군가 총대를 매고, 본인이 서버 역할을 해주기로 했다면
  다른 애들은 모르니까, 내가 임시 서버 역할을 해줄게! 이런 메세지를 보내는 것 
  temperal한 server가 activate 되었는데, 그게 나야! 뿌리는 것 
• 1초 쉬고, 메세지로 ip 주소 보내줌

 

• 연결 되는지 확인 -> 상대방이 있는지 확인하기 위해, 등록 서버 필요
  이 네트워크 안에 살아있는 peer node들이 누구인지 알아야지  
  p2p node가 살아나면, 비콘(서버) 확인, 나는 누구인지 서버에게 등록
• 서버 기능을 하는 애는 reply (reply request pattern으로 구현됨)
• user manager
  Node가 살아났을 때, 얘한테(임시 서버)한테 클라이언트 id, ip address 주는 것
  즉, user 등록을 하는 과정과 매세지 보내는 기능을 분리함!

 

• 모두 서버에 붙었다 (누가 서버인지 알고, 본인의 정보를 등록했으니)
  서버를 통해 메세지를 주고 받으면 된다. 
• pub 형태로 뿌리고, pull로 가져옴
• 메세지 받고, 화면에 출력하고, 통신 안에 있는 애들한테 뿌림 (-> 방송을 함) -> 무한 반복
• 일반적인 채팅 프로그램과 유사하게 p2p도 구현됨 
  24시간 살아있는 애가 서버가 되었다면, 이번에는 비콘 기능

 

•  개선할 점
  • 가입자 관리 - 저런 방식으로 뿌리는 것이 아니라, 의미 있는 애들끼리 묶어서 통신하자
  • 가입자 관리자 찾는 방법
  • 소켓 등 자원 사용의 효율화
  • Python외 언어를 통한 실제 모바일 앱 개발

 

 

 

• codon python
  • 새로운 성능이 좋은 파이썬 compiler
  • cpython -> native machine code 
  • virtual machine 이 아니라, mac 네이티브로
  • 머신러닝, 천체물리 등등 복잡한 계산을 한다면 추천