From 6647e61243fdfbdc600ef3bfbd15b7c2ca6e853e Mon Sep 17 00:00:00 2001 From: Martin Lucina Date: Sat, 4 Sep 2010 15:51:40 +0200 Subject: Revert "Small improvements to zmq_device(3) page" This reverts commit 96bcc9e6cf73781c31042278eb960c0363a78805. --- doc/zmq_device.txt | 32 ++++++++++---------------------- 1 file changed, 10 insertions(+), 22 deletions(-) (limited to 'doc/zmq_device.txt') diff --git a/doc/zmq_device.txt b/doc/zmq_device.txt index d5d7a18..6026559 100644 --- a/doc/zmq_device.txt +++ b/doc/zmq_device.txt @@ -31,13 +31,16 @@ Before calling _zmq_device()_ you must set any socket options, and connect or bind both frontend and backend sockets. The two conventional device models are: -* proxy model - accept inward connections to frontend socket (by binding it to - an endpoint), and make onward connections through backend socket (connecting - to endpoints on other nodes). A proxy device model can fit well into an - existing topology. -* broker model - accept connections on both frontend and backend sockets (by - binding both to endpoints). A broker device model creates a star topology - where nodes can come and go at any time. +*proxy*:: + bind frontend socket to an endpoint, and connect backend socket to + downstream components. A proxy device model does not require changes to + the downstream topology but that topology is static (any changes require + reconfiguring the device). +*broker*:: + bind frontend socket to one endpoint and bind backend socket to a second + endpoint. Downstream components must now connect into the device. A + broker device model allows a dynamic downstream topology (components can + come and go at any time). _zmq_device()_ runs in the current thread and returns only if/when the current context is closed. @@ -118,21 +121,6 @@ assert (zmq_bind (backend, "tcp://*:5556") == 0); zmq_device (ZMQ_QUEUE, frontend, backend); ---- -.Creating a pubsub proxy ----- -// Create frontend and backend sockets -void *frontend = zmq_socket (context, ZMQ_SUB); -assert (backend); -void *backend = zmq_socket (context, ZMQ_PUB); -assert (frontend); -// Connect frontend to publisher -assert (zmq_bind (frontend, "tcp://192.68.55.112:4444") == 0); -// Bind backend to TCP port -assert (zmq_bind (backend, "tcp://*:5556") == 0); -// Start a forwarder device -zmq_device (ZMQ_FORWARDER, frontend, backend); ----- - SEE ALSO -------- -- cgit v1.2.3 From 6c393f53e28f41118eed9a8d034d8d46f2555572 Mon Sep 17 00:00:00 2001 From: Martin Lucina Date: Sat, 4 Sep 2010 15:54:34 +0200 Subject: Revert "Further cleanups on reference manual" This reverts commit 13f3481e127a6b2390e847af6b01ee88f1b4ae61. Conflicts: doc/zmq_device.txt doc/zmq_tcp.txt --- doc/zmq_device.txt | 60 +++++++++++++----------------------------------------- 1 file changed, 14 insertions(+), 46 deletions(-) (limited to 'doc/zmq_device.txt') diff --git a/doc/zmq_device.txt b/doc/zmq_device.txt index 6026559..10d7445 100644 --- a/doc/zmq_device.txt +++ b/doc/zmq_device.txt @@ -13,8 +13,7 @@ SYNOPSIS DESCRIPTION ----------- -The _zmq_device()_ function starts a built-in 0MQ device. The 'device' -argument is one of: +The _zmq_device()_ function starts a built-in 0MQ device. The 'device' argument is one of: 'ZMQ_QUEUE':: starts a queue device @@ -23,86 +22,55 @@ argument is one of: 'ZMQ_STREAMER':: starts a streamer device -The device connects a frontend socket to a backend socket. Conceptually, data -flows from frontend to backend. Depending on the socket types, replies may -flow in the opposite direction. +The device connects a frontend socket to a backend socket. Conceptually, data flows from frontend to backend. Depending on the socket types, replies may flow in the opposite direction. -Before calling _zmq_device()_ you must set any socket options, and connect or -bind both frontend and backend sockets. The two conventional device models -are: +Before calling _zmq_device()_ you must set any socket options, and connect or bind both frontend and backend sockets. The two conventional device models are: *proxy*:: - bind frontend socket to an endpoint, and connect backend socket to - downstream components. A proxy device model does not require changes to - the downstream topology but that topology is static (any changes require - reconfiguring the device). + bind frontend socket to an endpoint, and connect backend socket to downstream components. A proxy device model does not require changes to the downstream topology but that topology is static (any changes require reconfiguring the device). *broker*:: - bind frontend socket to one endpoint and bind backend socket to a second - endpoint. Downstream components must now connect into the device. A - broker device model allows a dynamic downstream topology (components can - come and go at any time). + bind frontend socket to one endpoint and bind backend socket to a second endpoint. Downstream components must now connect into the device. A broker device model allows a dynamic downstream topology (components can come and go at any time). -_zmq_device()_ runs in the current thread and returns only if/when the current -context is closed. +_zmq_device()_ runs in the current thread and returns only if/when the current context is closed. QUEUE DEVICE ------------ -'ZMQ_QUEUE' creates a shared queue that collects requests from a set of -clients, and distributes these fairly among a set of services. Requests are -fair-queued from frontend connections and load-balanced between backend -connections. Replies automatically return to the client that made the original -request. +'ZMQ_QUEUE' creates a shared queue that collects requests from a set of clients, and distributes these fairly among a set of services. Requests are fair-queued from frontend connections and load-balanced between backend connections. Replies automatically return to the client that made the original request. -This device is part of the 'request-reply' pattern. The frontend speaks to -clients and the backend speaks to services. You should use 'ZMQ_QUEUE' with a -'ZMQ_XREP' socket for the frontend and a 'ZMQ_XREQ' socket for the backend. -Other combinations are not documented. +This device is part of the 'request-reply' pattern. The frontend speaks to clients and the backend speaks to services. You should use 'ZMQ_QUEUE' with a 'ZMQ_XREP' socket for the frontend and a 'ZMQ_XREQ' socket for the backend. Other combinations are not documented. Refer to linkzmq:zmq_socket[3] for a description of these socket types. FORWARDER DEVICE ---------------- -'ZMQ_FORWARDER' collects messages from a set of publishers and forwards these -to a set of subscribers. You will generally use this to bridge networks, e.g. -read on TCP unicast and forward on multicast. +'ZMQ_FORWARDER' collects messages from a set of publishers and forwards these to a set of subscribers. You will generally use this to bridge networks, e.g. read on TCP unicast and forward on multicast. -This device is part of the 'publish-subscribe' pattern. The frontend speaks to -publishers and the backend speaks to subscribers. You should use -'ZMQ_FORWARDER' with a 'ZMQ_SUB' socket for the frontend and a 'ZMQ_PUB' socket -for the backend. Other combinations are not documented. +This device is part of the 'publish-subscribe' pattern. The frontend speaks to publishers and the backend speaks to subscribers. You should use 'ZMQ_FORWARDER' with a 'ZMQ_SUB' socket for the frontend and a 'ZMQ_PUB' socket for the backend. Other combinations are not documented. Refer to linkzmq:zmq_socket[3] for a description of these socket types. STREAMER DEVICE --------------- -'ZMQ_STREAMER' collects tasks from a set of pushers and forwards these to a set -of pullers. You will generally use this to bridge networks. Messages are -fair-queued from pushers and load-balanced to pullers. +'ZMQ_STREAMER' collects tasks from a set of pushers and forwards these to a set of pullers. You will generally use this to bridge networks. Messages are fair-queued from pushers and load-balanced to pullers. -This device is part of the 'pipeline' pattern. The frontend speaks to pushers -and the backend speaks to pullers. You should use 'ZMQ_STREAMER' with a -'ZMQ_PULL' socket for the frontend and a 'ZMQ_PUSH' socket for the backend. -Other combinations are not documented. +This device is part of the 'pipeline' pattern. The frontend speaks to pushers and the backend speaks to pullers. You should use 'ZMQ_STREAMER' with a 'ZMQ_PULL' socket for the frontend and a 'ZMQ_PUSH' socket for the backend. Other combinations are not documented. Refer to linkzmq:zmq_socket[3] for a description of these socket types. RETURN VALUE ------------ +<<<<<<< HEAD The _zmq_device()_ function shall not return if successful. Otherwise it shall return `-1` and set 'errno' to one of the values defined below. ERRORS ------ -*ETERM*:: -The 0MQ 'context' associated with the specified 'frontend' or 'backend' was -terminated. -*EFAULT*:: -The provided 'frontend' or 'backend' was not valid (NULL). +The _zmq_device()_ function always returns `-1` and 'errno' set to *ETERM* (the 0MQ 'context' associated with either of the specified sockets was terminated). EXAMPLE -- cgit v1.2.3 From 26b39bcdef390f45bb316c4488b51470c27086e2 Mon Sep 17 00:00:00 2001 From: Martin Lucina Date: Sat, 4 Sep 2010 15:55:41 +0200 Subject: Revert "Added man page for the zmq_device method" This reverts commit f575f252c99c99d3622f313d6bbad6635197a1e4. Conflicts: doc/zmq_device.txt --- doc/zmq_device.txt | 99 ------------------------------------------------------ 1 file changed, 99 deletions(-) delete mode 100644 doc/zmq_device.txt (limited to 'doc/zmq_device.txt') diff --git a/doc/zmq_device.txt b/doc/zmq_device.txt deleted file mode 100644 index 10d7445..0000000 --- a/doc/zmq_device.txt +++ /dev/null @@ -1,99 +0,0 @@ -zmq_device(3) -============= - -NAME ----- -zmq_device - start built-in 0MQ device - - -SYNOPSIS --------- -*int zmq_device (int 'device', const void '*frontend', const void '*backend');* - - -DESCRIPTION ------------ -The _zmq_device()_ function starts a built-in 0MQ device. The 'device' argument is one of: - -'ZMQ_QUEUE':: - starts a queue device -'ZMQ_FORWARDER':: - starts a forwarder device -'ZMQ_STREAMER':: - starts a streamer device - -The device connects a frontend socket to a backend socket. Conceptually, data flows from frontend to backend. Depending on the socket types, replies may flow in the opposite direction. - -Before calling _zmq_device()_ you must set any socket options, and connect or bind both frontend and backend sockets. The two conventional device models are: - -*proxy*:: - bind frontend socket to an endpoint, and connect backend socket to downstream components. A proxy device model does not require changes to the downstream topology but that topology is static (any changes require reconfiguring the device). -*broker*:: - bind frontend socket to one endpoint and bind backend socket to a second endpoint. Downstream components must now connect into the device. A broker device model allows a dynamic downstream topology (components can come and go at any time). - -_zmq_device()_ runs in the current thread and returns only if/when the current context is closed. - - -QUEUE DEVICE ------------- -'ZMQ_QUEUE' creates a shared queue that collects requests from a set of clients, and distributes these fairly among a set of services. Requests are fair-queued from frontend connections and load-balanced between backend connections. Replies automatically return to the client that made the original request. - -This device is part of the 'request-reply' pattern. The frontend speaks to clients and the backend speaks to services. You should use 'ZMQ_QUEUE' with a 'ZMQ_XREP' socket for the frontend and a 'ZMQ_XREQ' socket for the backend. Other combinations are not documented. - -Refer to linkzmq:zmq_socket[3] for a description of these socket types. - - -FORWARDER DEVICE ----------------- -'ZMQ_FORWARDER' collects messages from a set of publishers and forwards these to a set of subscribers. You will generally use this to bridge networks, e.g. read on TCP unicast and forward on multicast. - -This device is part of the 'publish-subscribe' pattern. The frontend speaks to publishers and the backend speaks to subscribers. You should use 'ZMQ_FORWARDER' with a 'ZMQ_SUB' socket for the frontend and a 'ZMQ_PUB' socket for the backend. Other combinations are not documented. - -Refer to linkzmq:zmq_socket[3] for a description of these socket types. - - -STREAMER DEVICE ---------------- -'ZMQ_STREAMER' collects tasks from a set of pushers and forwards these to a set of pullers. You will generally use this to bridge networks. Messages are fair-queued from pushers and load-balanced to pullers. - -This device is part of the 'pipeline' pattern. The frontend speaks to pushers and the backend speaks to pullers. You should use 'ZMQ_STREAMER' with a 'ZMQ_PULL' socket for the frontend and a 'ZMQ_PUSH' socket for the backend. Other combinations are not documented. - -Refer to linkzmq:zmq_socket[3] for a description of these socket types. - - -RETURN VALUE ------------- -<<<<<<< HEAD -The _zmq_device()_ function shall not return if successful. Otherwise it shall -return `-1` and set 'errno' to one of the values defined below. - - -ERRORS ------- -The _zmq_device()_ function always returns `-1` and 'errno' set to *ETERM* (the 0MQ 'context' associated with either of the specified sockets was terminated). - - -EXAMPLE -------- -.Creating a queue broker ----- -// Create frontend and backend sockets -void *frontend = zmq_socket (context, ZMQ_XREP); -assert (backend); -void *backend = zmq_socket (context, ZMQ_XREQ); -assert (frontend); -// Bind both sockets to TCP ports -assert (zmq_bind (frontend, "tcp://*:5555") == 0); -assert (zmq_bind (backend, "tcp://*:5556") == 0); -// Start a queue device -zmq_device (ZMQ_QUEUE, frontend, backend); ----- - - -SEE ALSO --------- -linkzmq:zmq_bind[3] -linkzmq:zmq_connect[3] -linkzmq:zmq_socket[3] -linkzmq:zmq[7] - -- cgit v1.2.3