Libzmq Chapter 1 - Basics - Revision history

Pchero: /* Socket Scalability */

2016-08-02T23:47:26Z

Socket Scalability

← Older revision		Revision as of 23:47, 2 August 2016
Line 613:		Line 613:
	</pre>		</pre>
	잠시 위의 결과가 무엇을 의미하는지 생각해보자. weather server 는 단일 소켓을 가지고 있다. 그리고 5 개의 client 에게 병렬로 데이터를 전송하고 있다. 심지어 몇 천개의 client 를 연결할 수도 있다. 하지만 server 쪽에서는 이를 볼 수 없다. 이를 보면 ZeroMQ 는 마치 하나의 작은 서버로써 수 많은 client 의 요청과 데이터 전송을 묵묵히 수행하고 있는 것이다.		잠시 위의 결과가 무엇을 의미하는지 생각해보자. weather server 는 단일 소켓을 가지고 있다. 그리고 5 개의 client 에게 병렬로 데이터를 전송하고 있다. 심지어 몇 천개의 client 를 연결할 수도 있다. 하지만 server 쪽에서는 이를 볼 수 없다. 이를 보면 ZeroMQ 는 마치 하나의 작은 서버로써 수 많은 client 의 요청과 데이터 전송을 묵묵히 수행하고 있는 것이다.

			== Upgrading from ZeroMQ v2.2 to ZeroMQ v3.2 ==
			=== Compatible Changes ===
			=== Incompatible Changes ===
			=== Suggested Shim Macros ===
			== Warning: Unstable Paradigms! ==

	== See also ==		== See also ==

Pchero: /* Why We Needed ZeroMQ */

2016-08-02T23:46:18Z

Why We Needed ZeroMQ

← Older revision		Revision as of 23:46, 2 August 2016
Line 569:		Line 569:
	그리고 broker 중심의 방식은 그것을 관리하는 팀이 필요했다. 말 그대로 밤/낮으로 관리가 필요했다.		그리고 broker 중심의 방식은 그것을 관리하는 팀이 필요했다. 말 그대로 밤/낮으로 관리가 필요했다.

	[[File:Zmq fig8.png\|300px\|thumb\|~~left~~\|Messaging as it Becomes]]		[[File:Zmq fig8.png\|300px\|thumb\|right\|Messaging as it Becomes]]
	때문에 작거나 중간 크기의 어플리케이션 개발자들은 함정에 빠졌다. 불필요한 네트워크 프로그래밍을 피하기위해서는 어플리케이션의 크기를 작고 단순하게 유지해야만 했다. 아니면 어렵고 까다로운 네크워크 프로그래밍과 크기가 크고 복잡한 어플리케이션을 개발해야만 했다. 어느쪽도 쉽지 않았다. 혹은 비싸면서 성능이 좋지않은 사용제품을 구입해야만 했다.		때문에 작거나 중간 크기의 어플리케이션 개발자들은 함정에 빠졌다. 불필요한 네트워크 프로그래밍을 피하기위해서는 어플리케이션의 크기를 작고 단순하게 유지해야만 했다. 아니면 어렵고 까다로운 네크워크 프로그래밍과 크기가 크고 복잡한 어플리케이션을 개발해야만 했다. 어느쪽도 쉽지 않았다. 혹은 비싸면서 성능이 좋지않은 사용제품을 구입해야만 했다.

Line 589:		Line 589:
	* CPU 를 적게 사용한다.		* CPU 를 적게 사용한다.

	사실, ZeroMQ 는 이보다 더 많은 일들을 수행한다.		사실, ZeroMQ 는 이보다 더 많은 일들을 수행한다.

	== Socket Scalability ==		== Socket Scalability ==

Pchero: /* Why We Needed ZeroMQ */

2016-08-02T23:45:10Z

Why We Needed ZeroMQ

← Older revision		Revision as of 23:45, 2 August 2016
Line 563:		Line 563:

	재사용이 가능한 메시징 시스템을 만든다는 것은 굉장히 어려운 일이다. 이 때문에 굉장히 적은 수의 프로젝트들만이 이 메시징 시스템을 만드는 시도를 했으며, 이런 이유로 상업용 메시징 제품들은 복작하고, 비싸고, 유연하지 못하고, 조잡했다. 이러던 중, 2006년 iMatrix 에서 AMQP 를 디자인했는데 여전히 복잡하고, 비싸고, 조잡했다. 그리고 사용에 많은 시간이 걸렸다.		재사용이 가능한 메시징 시스템을 만든다는 것은 굉장히 어려운 일이다. 이 때문에 굉장히 적은 수의 프로젝트들만이 이 메시징 시스템을 만드는 시도를 했으며, 이런 이유로 상업용 메시징 제품들은 복작하고, 비싸고, 유연하지 못하고, 조잡했다. 이러던 중, 2006년 iMatrix 에서 AMQP 를 디자인했는데 여전히 복잡하고, 비싸고, 조잡했다. 그리고 사용에 많은 시간이 걸렸다.

			[[File:Zmq fig7.png\|300px\|thumb\|left\|Messaging as it Starts]]
			AMQP와 같은 대부분의 메시징 프로젝트들은 위에 나열한 여러가지 문제를 해결하면서도 재사용이 가능하도록 노력했다. 이들은 "broker"라는 새로운 컨셉을 만들었는데, addressing, routing, queuing 과 같은 작업을 관리한다. 이는 서버/클라이언트 프로토콜 혹은 API 등에서 프로토콜의 최상단에서 어플리케이션이 프토콜을 사용할 수 있도록 해주는 역할을 했다. broker는 대규모 네트워크에서의 복잡도를 놀랄정도로 줄여주었다. 하지만 Zookeeper 와 같은 제품에서는 좋은 결과를 얻지 못했다. 큰 시스템에 하나의 broker 를 추가한다는 것은 병목현상과 관리요소가 늘어난다는 것을 의미했다. 여러개의 broker 를 추가하는 방식으로 극복할 수 있었지만 여전히 복잡도가 높아지고, 고장날 위험이 높아지는 부담이 뒤따랐다.

			그리고 broker 중심의 방식은 그것을 관리하는 팀이 필요했다. 말 그대로 밤/낮으로 관리가 필요했다.

			[[File:Zmq fig8.png\|300px\|thumb\|left\|Messaging as it Becomes]]
			때문에 작거나 중간 크기의 어플리케이션 개발자들은 함정에 빠졌다. 불필요한 네트워크 프로그래밍을 피하기위해서는 어플리케이션의 크기를 작고 단순하게 유지해야만 했다. 아니면 어렵고 까다로운 네크워크 프로그래밍과 크기가 크고 복잡한 어플리케이션을 개발해야만 했다. 어느쪽도 쉽지 않았다. 혹은 비싸면서 성능이 좋지않은 사용제품을 구입해야만 했다.

			우리가 필요한 것은 간단하고, 비용이 들지않고, 아무 어플리케이션과도 잘 작동되는 메시징이었다. 쉽게 링크가 가능하면서도 의존성이 없는 라이브러리, 추가 위험성이 없으면서도 어떤 OS 및 언어와도 잘 작동하는 메시징 말이다.

			그게 바로 ZeroMQ 이다. 효과적이고, 즉시 사용이 가능하면서 비용이 없는 메시징 라이브러이다.

			* 백그라운드 쓰레드로 비동기 I/O를 수행한다. lock-free data structure 를 사용하기에 ZeroMQ 어플리케이션은 lock, semaphore 및 다른 어떤 대기 상태가 필요없이 동시 사용이 가능하다.
			* 컴포넌트들은 동적으로 활성/비활성 될 수 있으며, ZeroMQ에서는 자동적으로 재접속을 수행한다. 이 말은 순서에 상관없이 컴포넌트의 시작이 가능하다는 것이다. 이를 이용하면 네트워크에서 언제든 추가/해제가 가능한 "service-oriented architecture"(SOAs)를 구현할 수 있다.
			* 필요할 경우, 자동적으로 메시지를 Queuing 한다. 지능적으로 수행되며 수신쪽에서 최대한 Queueing 이 가능한 정도에 맞추도록 push 된다.
			* Over-full queue 을 다룰 수 있는 여러가지 방법을 제공한다("high water mark"). Queue 가 꽉 찼을 때, ZeroMQ 는 어떤 메시징을 하고 있느냐에 따라("pattern") 자동적으로 Sender 를 Block 하거나 메시지를 버린다.
			* 어플리케이션에서 임의의 Transport 계층을 사용할 수 있도록 해준다. TCP, multicast, in-process, inter-process, etc.. 서로 다른 Transport 계층 사용을 위해 코드를 재작성할 필요가 없게끔 해준다.
			* 메시징 패턴에 따라 서로 다른 전략으로 slow/block readers safe 를 한다.
			* 여러가지 패턴(request-reply, pub-sub, ...)을 통한 메시지 route 를 제공한다.
			* queue proxy, forward, capture 등을 제공한다.
			* 정확하게 메시지를 수신할 수 있도록 한다. 10k 메시지를 보냈다면, 10k 메시지를 수신한다.
			* 어떤 포멧도 강요하지 않는다. 0 에서 기가 바이트까지 전송이 가능하다.
			* 지능적으로 에러를 관리한다. 자동 재전송과 같은 기능을 수행한다.
			* CPU 를 적게 사용한다.

			사실, ZeroMQ 는 이보다 더 많은 일들을 수행한다.

			== Socket Scalability ==
			ZeroMQ 가 얼마나 감당할 수 있는지 확인해보자. weather server 와 여러개의 client 를 실행하는 간단한 스크립트이다.
			<source lang=bash>
			wuserver &
			wuclient 12345 &
			wuclient 23456 &
			wuclient 34567 &
			wuclient 45678 &
			wuclient 56789 &
			</source>

			Client 가 작동함에따라, top 명령어로 프로세스가 다음과 같이 작동하는 것을 확인할 수 있다.
			<pre>
			PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
			7136 ph 20 0 1040m 959m 1156 R 157 12.0 16:25.47 wuserver
			7966 ph 20 0 98608 1804 1372 S 33 0.0 0:03.94 wuclient
			7963 ph 20 0 33116 1748 1372 S 14 0.0 0:00.76 wuclient
			7965 ph 20 0 33116 1784 1372 S 6 0.0 0:00.47 wuclient
			7964 ph 20 0 33116 1788 1372 S 5 0.0 0:00.25 wuclient
			7967 ph 20 0 33072 1740 1372 S 5 0.0 0:00.35 wuclient
			</pre>
			잠시 위의 결과가 무엇을 의미하는지 생각해보자. weather server 는 단일 소켓을 가지고 있다. 그리고 5 개의 client 에게 병렬로 데이터를 전송하고 있다. 심지어 몇 천개의 client 를 연결할 수도 있다. 하지만 server 쪽에서는 이를 볼 수 없다. 이를 보면 ZeroMQ 는 마치 하나의 작은 서버로써 수 많은 client 의 요청과 데이터 전송을 묵묵히 수행하고 있는 것이다.

	== See also ==		== See also ==

Pchero: /* Why We Needed ZeroMQ */

2016-08-02T23:03:35Z

Why We Needed ZeroMQ

← Older revision		Revision as of 23:03, 2 August 2016
Line 541:		Line 541:

	== Why We Needed ZeroMQ ==		== Why We Needed ZeroMQ ==
			맛보기이긴 하지만 ZeroMQ 를 살펴보았다. 이제 "왜"라는 질문으로 돌아가보자.

			오늘날의 많은 어플리케이션들은 LAN/internet 과 같은 네트워크와 관련된 컴포넌트들을 가지고 있다. 즉, 결국 개발자들은 네트워크를 통한 메시징과 관련된 작업들을 해야하는데, 각각의 개발자마다 다루는 방식이 다르다. 이런 작업들이 비록 그렇게 어려운 작업은 아니지만, 바이트를 전송하는 것과 신뢰성있는 메시징을 하는것과는 큰 차이가 있다.

			TCP 를 사용할 경우, 어떤 문제점들에 직면하게되는지 간단히 살펴보도록 하자. 어떤 종류의 메시징 계층이든, 결국에는 비슷한 문제를 해결해야만 할 것이다.
			* I/O를 어떻게 다룰 것인가? 만약 어플리케이션이 먹통(block)일 경우, 혹은 I/O를 백그라운드로 관리할 수 있는가? Blocking I/O는 결국 Scale 의 문제에 부딫히게 된다. 반면에 백그라운드 작업은 굉장히 다루기가 힘들다는 문제가 있다.
			* 동적 컴포넌트(Dynamic component)들을 어떻게 다룰 것인가? 예를 들어 일시적으로 중지를 시켜야하는 경우라면? 서버/클라이언트를 정확하게 구분하고 서버가 항상 작동하도록 할 수 있을까? 매 초마다 재접속을 시도할 수 있을까?
			* 네트워크로 전송된 메시지를 어떻게 나타낼 수 있을까? 메시지를 프레임단위로 쪼개게 되면, 읽기, 쓰기 및 버퍼 오버플로우에 대처하기가 쉬워지겠지만, 대용량 비디오 스트리밍과 같은 경우는 어떻게 할 수 있을까?
			* 만약 메시지를 전송할수 없다면 어떻게 할 수 있을까? 컴포넌트가 다시 정상적으로 작동할 때 까지 기다려야 한다면? 메시지를 포기해야 할까? 데이터베이스에 쌓아두어야 할까? 메모리 큐에 입력해야 할까?
			* 메시지 큐를 어디에 적재할 수 있을까? 만약 컴포넌트의 Queue Reading 속도가 너무 느릴 경우 어떻게 할 수 있을까? 어떤 전략을 사용할 수 있을까?
			* 잃어버린 메시지는 어떻게 관리할 수 있을까? 새로운 데이터를 기다려야 할까? 재전송을 요청해야 할까? 아니면 별도의 신뢰성을 보장하는 새로운 계층을 만들어야 할까? 만약 계층 내에서 충돌이 발생하면 어떻게 해야 할까?
			* 만약 다른 종류의 Network transport 계층을 사용한다면 어떻게 될까? 예를 들어, TCP 단일 전송 대신, 다중 전송을 사용한다면? 혹은 IPv6? 어플리케이션을 새로 만들어야 할까? 가상 Transport 계층을 만들어야 할까?
			* 메시지를 어떻게 Route 할 수 있을까? 여러명에게 같은 메시지를 전송할 수 있을까? 최초 요청자에게 정확한 메시지를 응답할 수 있을까?
			* 어떻게 다른 언어들에 대한 API 를 제공할 수 있을까? wire-level 프로토콜을 재구현해야할까? 패키지 방식의 라이브러리로 제공해야 할까? 안정성문제는 없을까? 어떻게 보증할 수 있을까?
			* 서로 다른 아키텍쳐 사이의 데이터 전송시 아무런 문제가 없을까? 반드시 인코딩/디코딩을 하도록 해야할까?
			* 네트워크 에러는 어떻게 대처할 수 있을까? 재전송해야할까? 기다려야할까? 그냥 무시해야할까? 프로그램 종료를 해야할까?

			Hadoop Zookeeper 와 같은 오픈소스를 들여다보자. 2013년 1월 경 소스를 확인하면, 서버/클라이언트 네트워크 통신 프로토콜을 위해 약 4,200 줄의 신비스럽고(미스테리한) 문서화되지 않은 소스코드가 있었다. select 대신 poll 을 사용한 것으로 보아 굉장히 효율적인 것이라는 것을 알수 있다.하지만 Zookeeper 는 단순히 작동하는 것 이상으로 잘 정리된 문서와, 잘 가상화된 계층 레이어가 있었어야만 했다. 매번 사람들이 이를 재구현해야만 한다면 얼마나 큰 낭비이겠는가?

			그런데, 어떻게 재사용이 가능한 메시지 계층을 만들 수 있을까? 왜 많은 프로젝트에서 이 기술이 필요한 걸까? 사람들이 TCP 소켓을 사용할때마다 늘 이런 작업들을 처리해야만 하는 걸까?

			재사용이 가능한 메시징 시스템을 만든다는 것은 굉장히 어려운 일이다. 이 때문에 굉장히 적은 수의 프로젝트들만이 이 메시징 시스템을 만드는 시도를 했으며, 이런 이유로 상업용 메시징 제품들은 복작하고, 비싸고, 유연하지 못하고, 조잡했다. 이러던 중, 2006년 iMatrix 에서 AMQP 를 디자인했는데 여전히 복잡하고, 비싸고, 조잡했다. 그리고 사용에 많은 시간이 걸렸다.

	== See also ==		== See also ==

Pchero: /* Making a Clean Exit */

2016-07-19T23:23:35Z

Making a Clean Exit

@@ Line 522: / Line 522: @@
 유명한 프로그래밍 명언이 있다. "always clean-up when you finish the job". ZeroMQ 를 사용할 때, 가령 python 의 경우, 할당된 메모리는 자동적으로 해제된다. 하지만 C 를 사용할 경우, 메모리 해제에 주의를 기울여야 한다. 그렇지 않으면, 메모리 누수, 불안정한 어플리케이션, 그리고 업보가 쌓일 것이다.
-메모리 누수는 원인은 한가지다. 하지만 ZeroMQ 의 . 그 이유는 굉장히 기술적인 부분이며 고통스럽다.
+ZeroMQ 에서의 메모리 관리는 굉장히 엄격하다. 그 이유는 굉장히 기술적인 부분이며 고통스럽다. 결론적으로 만약 하나의 socket 이라도 open 되어 있는 상태에서 zmq_ctx_destroy() 를 할 경우, 영원히 대기상태가 될 것이다. 그리고, 만약 모든 socket 을 close 한 상태라도, zmq_ctx_destroy() 은 기본적으로 현재 pending 중인 connect 가 있다면 작업이 종료될 때 까지 대기하게 된다. 또, close 함 socket 이라도 close 전 LINGER 를 0으로 설정하지 않은 상태에서 전송할 메시지가 있는 경우 이 역시 작업이 종료될 때 까지 계속 대기하게 된다.
 == See also ==

Pchero: /* Making a Clean Exit */

2016-07-19T22:56:22Z

Making a Clean Exit

← Older revision		Revision as of 22:56, 19 July 2016
Line 520:		Line 520:

	=== Making a Clean Exit ===		=== Making a Clean Exit ===
			유명한 프로그래밍 명언이 있다. "always clean-up when you finish the job". ZeroMQ 를 사용할 때, 가령 python 의 경우, 할당된 메모리는 자동적으로 해제된다. 하지만 C 를 사용할 경우, 메모리 해제에 주의를 기울여야 한다. 그렇지 않으면, 메모리 누수, 불안정한 어플리케이션, 그리고 업보가 쌓일 것이다.

			메모리 누수는 원인은 한가지다. 하지만 ZeroMQ 의 . 그 이유는 굉장히 기술적인 부분이며 고통스럽다.

	== See also ==		== See also ==

Pchero: /* Divide and Conquer */

2016-07-19T22:39:54Z

Divide and Conquer

← Older revision		Revision as of 22:39, 19 July 2016
Line 500:		Line 500:
	* sink 의 PULL socket 은 worker 들로부터 작업 결과를 골고루 수집한다. 이를 fair-queuing 이라고 한다.		* sink 의 PULL socket 은 worker 들로부터 작업 결과를 골고루 수집한다. 이를 fair-queuing 이라고 한다.

	[[File:Zmq ~~Fig6~~.png\|300px\|thumb\|left\|Fair Queuing]]		[[File:Zmq fig6.png\|300px\|thumb\|left\|Fair Queuing]]
	Pipeline pattern 은 "slow joiner" 현상을. 만약 PUSH 와 PULL 을 사용한다면, worker 들 중 하나는 다른 worker 에 비해 더 많은 메시지를 수신하게 될 것이다. 왜냐하면 PULL socket 은 보다 빨리 join 되기 때문에 다른 소켓들에 비해 많은 양의 메시지들을 수신하기 때문이다. 만약 로드 밸런싱(load balancing)을 원한다면 Chapter 3 - Advanced Request-Reply Patterns 에서 load balancing 패턴을 보길바란다.		Pipeline pattern 은 "slow joiner" 현상을. 만약 PUSH 와 PULL 을 사용한다면, worker 들 중 하나는 다른 worker 에 비해 더 많은 메시지를 수신하게 될 것이다. 왜냐하면 PULL socket 은 보다 빨리 join 되기 때문에 다른 소켓들에 비해 많은 양의 메시지들을 수신하기 때문이다. 만약 로드 밸런싱(load balancing)을 원한다면 Chapter 3 - Advanced Request-Reply Patterns 에서 load balancing 패턴을 보길바란다.

Pchero: /* Programming with ZeroMQ */

2016-07-19T22:39:10Z

Programming with ZeroMQ

← Older revision		Revision as of 22:39, 19 July 2016
Line 504:		Line 504:

	== Programming with ZeroMQ ==		== Programming with ZeroMQ ==
			이제껏 예제들을 봤으니 지금쯤이면 ZeroMQ 를 이용해서 어플리케이션을 만들고 싶을 것이다. 하지만 시작하기 전에, 심호흡을 하고, 진정하고, 당신의 스트레스와 고민을 줄여줄 아래의 글들을 읽어보도록 하자.

			* ZeroMQ 을 한걸음씩 배우자. 단순한 API 로 보일지도 모른다. 하지만 내부적으로 수 많은 가능성을 가지고 있다. 천천히, 한번에 하나씩, 마스터하길 바란다.
			* 읽기 좋은 코드를 만들자. 읽기 나쁜 코드는 문제점들을 숨기고, 다른사람들이 알아보기 힘들게 만든다. 의미없은 변수 이름을 작성할 수도 있다. 하지만 사람들이 그 코드를 봤을때는 혼란스러울 수 있다. 알아보기 쉬운 변수명을 작성하도록 하자. 그리고 일관성있는 들여쓰기 역시 읽기 좋은 코드를 만든다.
			* 만들고자 했던 내용으로 테스트를 하자. 당신의 프로그램이 제대로 작동하지 않을 때, 어떤 라인에서 문제가 발생했는지 알 수 있을 것이다. 특히 ZeroMQ 를 사용할 경우, 단 몇번의 테스트 만으로도 어디가 문제인지 바로 알 수가 있다.
			* 만약 프로그램이 의도한대로 작동하지 않는다면, 코드를 잘게 쪼개도록 하자. 그리고 하나씩 테스트를 해서 어느 부분이 정상적으로 작동하지 않는지를 확인하자. ZeroMQ 는 코드를 잘게 쪼갤 수 있도록 도와준다. 엄청난 이점이다.
			* 필요한 만큼 추상화(클래스, 메소드, 뭐가되었든)를 하자. 코드를 복사하고 붙여넣기를 하게되면, 정확히 그만큼의 에러도 같이 복사하고 붙여넣기를 하는 것이다.

			=== Getting the Context Right ===
			ZeroMQ 어플리케이션은 항상 context 를 만들고, 이를 이용해서 socket 을 생성한다. C 에서는 zmq_ctx_new()를 호출한다. 하나의 프로세스에서는 반드시 하나의 context 만 생성해야 한다. 기술적으로, context 는 프로세스의 모든 소켓들을 위한 컨테이너와 같은 역할을 하며, inproc 소켓(프로세스 내에서 가장 빠른 쓰레드 연결)들의 Transport 역할을 한다. 만약 실행중인 프로세스에 2 개의 context 가 있다면, 두개의 다른 ZeroMQ instance 처럼 작동할 것이다. 만약 반드시 그렇게 해야만 하는 이유가 있다면, 2개 이상의 context 를 생성해도 된다. 하지만 그 외의 경우라면 다음을 기억하자.

			* 프로세스의 시작에 zmq_ctx_new() 를 한번만 호출하고, 프로세스의 마지막에 zmq_ctw_destroy() 를 호출하자.

			만약 fork() 시스템 콜을 사용중이라면, zmq_ctx_new() 를 fork() 이후, child 프로세스의 시작부분에서 호출 하면 된다.

			=== Making a Clean Exit ===

	== See also ==		== See also ==

Pchero: /* Divide and Conquer */

2016-07-19T22:14:30Z

Divide and Conquer

← Older revision		Revision as of 22:14, 19 July 2016
Line 499:		Line 499:
	* ventilator 의 PUSH socket 은 작업을 worker 들에게 분배를 한다(이미 모든 worker 들이 접속해있는 상태라고 가정하자). 이를 로드 밸런신(load balancing)이라고 하며, 나중에 다시 살펴볼 것이다.		* ventilator 의 PUSH socket 은 작업을 worker 들에게 분배를 한다(이미 모든 worker 들이 접속해있는 상태라고 가정하자). 이를 로드 밸런신(load balancing)이라고 하며, 나중에 다시 살펴볼 것이다.
	* sink 의 PULL socket 은 worker 들로부터 작업 결과를 골고루 수집한다. 이를 fair-queuing 이라고 한다.		* sink 의 PULL socket 은 worker 들로부터 작업 결과를 골고루 수집한다. 이를 fair-queuing 이라고 한다.

			[[File:Zmq Fig6.png\|300px\|thumb\|left\|Fair Queuing]]
			Pipeline pattern 은 "slow joiner" 현상을. 만약 PUSH 와 PULL 을 사용한다면, worker 들 중 하나는 다른 worker 에 비해 더 많은 메시지를 수신하게 될 것이다. 왜냐하면 PULL socket 은 보다 빨리 join 되기 때문에 다른 소켓들에 비해 많은 양의 메시지들을 수신하기 때문이다. 만약 로드 밸런싱(load balancing)을 원한다면 Chapter 3 - Advanced Request-Reply Patterns 에서 load balancing 패턴을 보길바란다.

			== Programming with ZeroMQ ==

	== See also ==		== See also ==

Pchero: /* Divide and Conquer */

2016-07-19T22:00:11Z

Divide and Conquer

Show changes