zmq_ipc(7) [debian man page]
ZMQ_IPC(7) 0MQ Manual ZMQ_IPC(7) NAME
zmq_ipc - 0MQ local inter-process communication transport SYNOPSIS
The inter-process transport passes messages between local processes using a system-dependent IPC mechanism. Note The inter-process transport is currently only implemented on operating systems that provide UNIX domain sockets. ADDRESSING
A 0MQ address string consists of two parts as follows: transport://endpoint. The transport part specifies the underlying transport protocol to use, and for the inter-process transport shall be set to ipc. The meaning of the endpoint part for the inter-process transport is defined below. Assigning a local address to a socket When assigning a local address to a socket using zmq_bind() with the ipc transport, the endpoint shall be interpreted as an arbitrary string identifying the pathname to create. The pathname must be unique within the operating system namespace used by the ipc implementation, and must fulfill any restrictions placed by the operating system on the format and length of a pathname. Connecting a socket When connecting a socket to a peer address using zmq_connect() with the ipc transport, the endpoint shall be interpreted as an arbitrary string identifying the pathname to connect to. The pathname must have been previously created within the operating system namespace by assigning it to a socket with zmq_bind(). WIRE FORMAT
Not applicable. EXAMPLES
Assigning a local address to a socket. /* Assign the pathname "/tmp/feeds/0" */ rc = zmq_bind(socket, "ipc:///tmp/feeds/0"); assert (rc == 0); Connecting a socket. /* Connect to the pathname "/tmp/feeds/0" */ rc = zmq_connect(socket, "ipc:///tmp/feeds/0"); assert (rc == 0); SEE ALSO
zmq_bind(3) zmq_connect(3) zmq_inproc(7) zmq_tcp(7) zmq_pgm(7) zmq(7) AUTHORS
This manual page was written by the 0MQ community. 0MQ 2.2.0 04/04/2012 ZMQ_IPC(7)
Check Out this Related Man Page
ZMQ_DEVICE(3) 0MQ Manual 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 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 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 zmq_socket(3) for a description of these socket types. RETURN VALUE
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
zmq_bind(3) zmq_connect(3) zmq_socket(3) zmq(7) AUTHORS
This manual page was written by the 0MQ community. 0MQ 2.2.0 04/04/2012 ZMQ_DEVICE(3)