이전 글에서 프록시를 소개하면서 단순한 REQ – REP 패턴의 네트워크 중간에 중간 매개로 프록시를 넣어 REQ – ROUTER – DEALER – REP 형태로 패턴을 확장하는 예를 살펴보았다. 이 때, ROUTER – DEALER 사이에서 오가는 데이터를 보면 REQ-REP 사이에서 오가는 데이터와 다르게 추가된 프레임이 보인다는 것을 볼 수 있었다. 이번 글에서는 이런 현상은 왜 일어나며, ROUTER가 무슨 짓을 벌이는지에 대해 소개하고자 한다. 적어도 이 개념을 이해한다면 ZMQ를 통해서 훨씬 더 유연하고 창의적인(?) 패턴을 만드는 것도 가능하리라고 본다. 먼저 간단한 REQ-REP 패턴에서… 더 보기 »ZMQ 소켓 – Dealer, Router 이해하기
ZMQ 디바이스를 사용하여 네트워크를 확장하는 예를 살펴본 적이 있었는데, 사실 ‘디바이스’라는 개념은 zmq 내에서도 너무 오래되었고, 이제는 프록시 라는 개념으로 대체됐다. 디바이스와 프록시의 차이를 알아보고 프록시는 어떤 형태로 사용하는지 살펴보자.
더 보기 »ZMQ 프록시 사용하기멀티파트 메시지는 하나의 메시지 프레임 내부에 여러 개의 독립적인 메시지 프레임이 들어 있는 것을 말한다. 이는 하나의 프레임에서 처리하기 힘든 데이터 조각들을 모아서 처리할 때 유용하다. 예를 들어 바이너리 파일 데이터를 전송하려는 경우에는 보내는 쪽이나 받는 쪽이나 전송하는 데이터가 이진데이터라는 것을 알고 있다 가정하여 바이트 스트림을 전송할 수 있다. 하지만 이렇게 하면 실제 데이터 외부에 있었던 정보, 이를 테면 파일 이름이나 생성한 날짜 같은 메타 정보를 전달하기가 어려워진다. 이런 경우 여러 정보들을 멀티 파트 메시지로 묶어서 하나의 프레임으로 전송하면 필요한… 더 보기 »ZMQ 멀티파트메시지
일반적인 소켓 연결의 경우, 주로 서버는 bind()를 통해서 포트에 연결하고 클라이언트는 connect()를 사용해서 포트에 연결한다. ZMQ에서는 이 방식이 절대적인 규칙이 아니다. 간단한 소켓 통신의 예에서 양 끝단 중 상대적으로 안정적인 쪽이 서버인 경우가 많기 때문에 bind() 하는 것이며 클라이언트는 서버보다는 동적이기 때문에 connect() 하는 경우가 많을 뿐이다. 간단한 피어 통신의 예제에서는 사실 양 끝단이 모두 ‘고정’되어 있고, ZMQ에서는 연결의 순서에 구애받지 않으므로 클라이언트가 bind()를 하고 서버가 connect()를 해도 문제 없다. 유념해야하는 원칙 한가지는 안정적인 쪽이 bind()를, 그렇지 않은 쪽이 connect()를… 더 보기 »ZMQ 디바이스 사용하기