From e645fc2693acc796304498909786b7b47005b429 Mon Sep 17 00:00:00 2001 From: Martin Lucina Date: Mon, 23 Jan 2012 08:53:35 +0100 Subject: Imported Upstream version 2.1.3 --- doc/Makefile.am | 20 +- doc/Makefile.in | 106 ++-- doc/zmq.7 | 34 +- doc/zmq.html | 866 --------------------------- doc/zmq.txt | 32 +- doc/zmq_bind.3 | 13 +- doc/zmq_bind.html | 738 ----------------------- doc/zmq_bind.txt | 4 +- doc/zmq_close.3 | 28 +- doc/zmq_close.html | 635 -------------------- doc/zmq_close.txt | 18 +- doc/zmq_connect.3 | 13 +- doc/zmq_connect.html | 724 ----------------------- doc/zmq_connect.txt | 4 +- doc/zmq_cpp.7 | 12 +- doc/zmq_cpp.html | 763 ------------------------ doc/zmq_cpp.txt | 4 +- doc/zmq_device.3 | 140 +++++ doc/zmq_device.txt | 138 +++++ doc/zmq_epgm.7 | 14 +- doc/zmq_epgm.html | 745 ----------------------- doc/zmq_epgm.txt | 8 +- doc/zmq_errno.3 | 10 +- doc/zmq_errno.html | 634 -------------------- doc/zmq_errno.txt | 4 +- doc/zmq_forwarder.1 | 57 -- doc/zmq_forwarder.html | 613 ------------------- doc/zmq_forwarder.txt | 33 -- doc/zmq_getsockopt.3 | 445 +++++++++++++- doc/zmq_getsockopt.html | 1202 ------------------------------------- doc/zmq_getsockopt.txt | 180 +++++- doc/zmq_init.3 | 12 +- doc/zmq_init.html | 632 -------------------- doc/zmq_init.txt | 7 +- doc/zmq_inproc.7 | 8 +- doc/zmq_inproc.html | 669 --------------------- doc/zmq_inproc.txt | 2 +- doc/zmq_ipc.7 | 8 +- doc/zmq_ipc.html | 662 --------------------- doc/zmq_ipc.txt | 2 +- doc/zmq_msg_close.3 | 8 +- doc/zmq_msg_close.html | 638 -------------------- doc/zmq_msg_close.txt | 2 +- doc/zmq_msg_copy.3 | 8 +- doc/zmq_msg_copy.html | 647 -------------------- doc/zmq_msg_copy.txt | 2 +- doc/zmq_msg_data.3 | 8 +- doc/zmq_msg_data.html | 633 -------------------- doc/zmq_msg_data.txt | 2 +- doc/zmq_msg_init.3 | 8 +- doc/zmq_msg_init.html | 656 --------------------- doc/zmq_msg_init.txt | 2 +- doc/zmq_msg_init_data.3 | 8 +- doc/zmq_msg_init_data.html | 669 --------------------- doc/zmq_msg_init_data.txt | 2 +- doc/zmq_msg_init_size.3 | 8 +- doc/zmq_msg_init_size.html | 656 --------------------- doc/zmq_msg_init_size.txt | 2 +- doc/zmq_msg_move.3 | 8 +- doc/zmq_msg_move.html | 636 -------------------- doc/zmq_msg_move.txt | 2 +- doc/zmq_msg_size.3 | 8 +- doc/zmq_msg_size.html | 633 -------------------- doc/zmq_msg_size.txt | 2 +- doc/zmq_pgm.7 | 14 +- doc/zmq_pgm.html | 745 ----------------------- doc/zmq_pgm.txt | 8 +- doc/zmq_poll.3 | 44 +- doc/zmq_poll.html | 764 ------------------------ doc/zmq_poll.txt | 21 +- doc/zmq_queue.1 | 57 -- doc/zmq_queue.html | 613 ------------------- doc/zmq_queue.txt | 33 -- doc/zmq_recv.3 | 13 +- doc/zmq_recv.html | 729 ----------------------- doc/zmq_recv.txt | 5 +- doc/zmq_send.3 | 15 +- doc/zmq_send.html | 735 ----------------------- doc/zmq_send.txt | 7 +- doc/zmq_setsockopt.3 | 306 +++++++++- doc/zmq_setsockopt.html | 1277 ---------------------------------------- doc/zmq_setsockopt.txt | 125 +++- doc/zmq_socket.3 | 76 +-- doc/zmq_socket.html | 1403 -------------------------------------------- doc/zmq_socket.txt | 82 +-- doc/zmq_streamer.1 | 57 -- doc/zmq_streamer.html | 613 ------------------- doc/zmq_streamer.txt | 33 -- doc/zmq_strerror.3 | 8 +- doc/zmq_strerror.html | 634 -------------------- doc/zmq_strerror.txt | 2 +- doc/zmq_tcp.7 | 14 +- doc/zmq_tcp.html | 755 ------------------------ doc/zmq_tcp.txt | 8 +- doc/zmq_term.3 | 67 ++- doc/zmq_term.html | 658 --------------------- doc/zmq_term.txt | 36 +- doc/zmq_version.3 | 10 +- doc/zmq_version.html | 632 -------------------- doc/zmq_version.txt | 4 +- 100 files changed, 1748 insertions(+), 24342 deletions(-) delete mode 100644 doc/zmq.html delete mode 100644 doc/zmq_bind.html delete mode 100644 doc/zmq_close.html delete mode 100644 doc/zmq_connect.html delete mode 100644 doc/zmq_cpp.html create mode 100644 doc/zmq_device.3 create mode 100644 doc/zmq_device.txt delete mode 100644 doc/zmq_epgm.html delete mode 100644 doc/zmq_errno.html delete mode 100644 doc/zmq_forwarder.1 delete mode 100644 doc/zmq_forwarder.html delete mode 100644 doc/zmq_forwarder.txt delete mode 100644 doc/zmq_getsockopt.html delete mode 100644 doc/zmq_init.html delete mode 100644 doc/zmq_inproc.html delete mode 100644 doc/zmq_ipc.html delete mode 100644 doc/zmq_msg_close.html delete mode 100644 doc/zmq_msg_copy.html delete mode 100644 doc/zmq_msg_data.html delete mode 100644 doc/zmq_msg_init.html delete mode 100644 doc/zmq_msg_init_data.html delete mode 100644 doc/zmq_msg_init_size.html delete mode 100644 doc/zmq_msg_move.html delete mode 100644 doc/zmq_msg_size.html delete mode 100644 doc/zmq_pgm.html delete mode 100644 doc/zmq_poll.html delete mode 100644 doc/zmq_queue.1 delete mode 100644 doc/zmq_queue.html delete mode 100644 doc/zmq_queue.txt delete mode 100644 doc/zmq_recv.html delete mode 100644 doc/zmq_send.html delete mode 100644 doc/zmq_setsockopt.html delete mode 100644 doc/zmq_socket.html delete mode 100644 doc/zmq_streamer.1 delete mode 100644 doc/zmq_streamer.html delete mode 100644 doc/zmq_streamer.txt delete mode 100644 doc/zmq_strerror.html delete mode 100644 doc/zmq_tcp.html delete mode 100644 doc/zmq_term.html delete mode 100644 doc/zmq_version.html (limited to 'doc') diff --git a/doc/Makefile.am b/doc/Makefile.am index ba2b64a..d00014d 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -1,5 +1,5 @@ -MAN1 = zmq_forwarder.1 zmq_streamer.1 zmq_queue.1 -MAN3 = zmq_bind.3 zmq_close.3 zmq_connect.3 zmq_init.3 \ +MAN1 = +MAN3 = zmq_bind.3 zmq_close.3 zmq_connect.3 zmq_device.3 zmq_init.3 \ zmq_msg_close.3 zmq_msg_copy.3 zmq_msg_data.3 zmq_msg_init.3 \ zmq_msg_init_data.3 zmq_msg_init_size.3 zmq_msg_move.3 zmq_msg_size.3 \ zmq_poll.3 zmq_recv.3 zmq_send.3 zmq_setsockopt.3 zmq_socket.3 \ @@ -11,7 +11,6 @@ MAN_DOC = $(MAN1) $(MAN3) $(MAN7) MAN_TXT = $(MAN1:%.1=%.txt) MAN_TXT += $(MAN3:%.3=%.txt) MAN_TXT += $(MAN7:%.7=%.txt) -MAN_HTML = $(MAN_TXT:%.txt=%.html) if INSTALL_MAN dist_man_MANS = $(MAN_DOC) @@ -27,20 +26,17 @@ MAINTAINERCLEANFILES = $(MAN_DOC) $(MAN_HTML) dist-hook : $(MAN_DOC) $(MAN_HTML) if BUILD_DOC -SUFFIXES=.html .txt .xml .1 .3 .7 +SUFFIXES=.txt .xml .1 .3 .7 -.txt.html: - asciidoc -d manpage -b xhtml11 -f asciidoc.conf \ - -azmq_version=@PACKAGE_VERSION@ $< .txt.xml: - asciidoc -d manpage -b docbook -f asciidoc.conf \ + $(AM_V_GEN)$(ASCIIDOC) -d manpage -b docbook -f asciidoc.conf \ -azmq_version=@PACKAGE_VERSION@ $< .xml.1: - xmlto man $< + $(AM_V_GEN)$(XMLTO) man $< .xml.3: - xmlto man $< + $(AM_V_GEN)$(XMLTO) man $< .xml.7: - xmlto man $< + $(AM_V_GEN)$(XMLTO) man $< zmq_epgm.7: zmq_pgm.7 - cp zmq_pgm.7 $@ + $(AM_V_GEN)cp zmq_pgm.7 $@ endif diff --git a/doc/Makefile.in b/doc/Makefile.in index 4a1c0c2..0d71c0e 100644 --- a/doc/Makefile.in +++ b/doc/Makefile.in @@ -42,13 +42,20 @@ am__aclocal_m4_deps = $(top_srcdir)/config/libtool.m4 \ $(top_srcdir)/config/ltoptions.m4 \ $(top_srcdir)/config/ltsugar.m4 \ $(top_srcdir)/config/ltversion.m4 \ - $(top_srcdir)/config/lt~obsolete.m4 $(top_srcdir)/configure.in + $(top_srcdir)/config/lt~obsolete.m4 $(top_srcdir)/acinclude.m4 \ + $(top_srcdir)/configure.in am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \ $(ACLOCAL_M4) mkinstalldirs = $(install_sh) -d CONFIG_HEADER = $(top_builddir)/src/platform.hpp CONFIG_CLEAN_FILES = CONFIG_CLEAN_VPATH_FILES = +AM_V_GEN = $(am__v_GEN_$(V)) +am__v_GEN_ = $(am__v_GEN_$(AM_DEFAULT_VERBOSITY)) +am__v_GEN_0 = @echo " GEN " $@; +AM_V_at = $(am__v_at_$(V)) +am__v_at_ = $(am__v_at_$(AM_DEFAULT_VERBOSITY)) +am__v_at_0 = @ SOURCES = DIST_SOURCES = am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`; @@ -72,18 +79,18 @@ am__nobase_list = $(am__nobase_strip_setup); \ am__base_list = \ sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \ sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g' -man1dir = $(mandir)/man1 -am__installdirs = "$(DESTDIR)$(man1dir)" "$(DESTDIR)$(man3dir)" \ - "$(DESTDIR)$(man7dir)" man3dir = $(mandir)/man3 +am__installdirs = "$(DESTDIR)$(man3dir)" "$(DESTDIR)$(man7dir)" man7dir = $(mandir)/man7 NROFF = nroff MANS = $(dist_man_MANS) DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) ACLOCAL = @ACLOCAL@ AMTAR = @AMTAR@ +AM_DEFAULT_VERBOSITY = @AM_DEFAULT_VERBOSITY@ AR = @AR@ AS = @AS@ +ASCIIDOC = @ASCIIDOC@ AUTOCONF = @AUTOCONF@ AUTOHEADER = @AUTOHEADER@ AUTOMAKE = @AUTOMAKE@ @@ -109,8 +116,6 @@ ECHO_T = @ECHO_T@ EGREP = @EGREP@ EXEEXT = @EXEEXT@ FGREP = @FGREP@ -GLIB_CFLAGS = @GLIB_CFLAGS@ -GLIB_LIBS = @GLIB_LIBS@ GREP = @GREP@ INSTALL = @INSTALL@ INSTALL_DATA = @INSTALL_DATA@ @@ -122,6 +127,7 @@ LDFLAGS = @LDFLAGS@ LIBOBJS = @LIBOBJS@ LIBS = @LIBS@ LIBTOOL = @LIBTOOL@ +LIBZMQ_EXTRA_CFLAGS = @LIBZMQ_EXTRA_CFLAGS@ LIBZMQ_EXTRA_CXXFLAGS = @LIBZMQ_EXTRA_CXXFLAGS@ LIBZMQ_EXTRA_LDFLAGS = @LIBZMQ_EXTRA_LDFLAGS@ LIPO = @LIPO@ @@ -144,13 +150,13 @@ PACKAGE_TARNAME = @PACKAGE_TARNAME@ PACKAGE_URL = @PACKAGE_URL@ PACKAGE_VERSION = @PACKAGE_VERSION@ PATH_SEPARATOR = @PATH_SEPARATOR@ -PKG_CONFIG = @PKG_CONFIG@ RANLIB = @RANLIB@ SED = @SED@ SET_MAKE = @SET_MAKE@ SHELL = @SHELL@ STRIP = @STRIP@ VERSION = @VERSION@ +XMLTO = @XMLTO@ abs_builddir = @abs_builddir@ abs_srcdir = @abs_srcdir@ abs_top_builddir = @abs_top_builddir@ @@ -158,6 +164,8 @@ abs_top_srcdir = @abs_top_srcdir@ ac_ct_CC = @ac_ct_CC@ ac_ct_CXX = @ac_ct_CXX@ ac_ct_DUMPBIN = @ac_ct_DUMPBIN@ +ac_zmq_have_asciidoc = @ac_zmq_have_asciidoc@ +ac_zmq_have_xmlto = @ac_zmq_have_xmlto@ am__include = @am__include@ am__leading_dot = @am__leading_dot@ am__quote = @am__quote@ @@ -175,12 +183,6 @@ datarootdir = @datarootdir@ docdir = @docdir@ dvidir = @dvidir@ exec_prefix = @exec_prefix@ -have_asciidoc = @have_asciidoc@ -have_gzip = @have_gzip@ -have_perl = @have_perl@ -have_pkg_config = @have_pkg_config@ -have_python = @have_python@ -have_xmlto = @have_xmlto@ host = @host@ host_alias = @host_alias@ host_cpu = @host_cpu@ @@ -190,7 +192,6 @@ htmldir = @htmldir@ includedir = @includedir@ infodir = @infodir@ install_sh = @install_sh@ -inttypes = @inttypes@ libdir = @libdir@ libexecdir = @libexecdir@ localedir = @localedir@ @@ -201,20 +202,21 @@ mkdir_p = @mkdir_p@ oldincludedir = @oldincludedir@ pdfdir = @pdfdir@ pgm_basename = @pgm_basename@ +pgm_srcdir = @pgm_srcdir@ prefix = @prefix@ program_transform_name = @program_transform_name@ psdir = @psdir@ sbindir = @sbindir@ sharedstatedir = @sharedstatedir@ srcdir = @srcdir@ -stdint = @stdint@ +subdirs = @subdirs@ sysconfdir = @sysconfdir@ target_alias = @target_alias@ top_build_prefix = @top_build_prefix@ top_builddir = @top_builddir@ top_srcdir = @top_srcdir@ -MAN1 = zmq_forwarder.1 zmq_streamer.1 zmq_queue.1 -MAN3 = zmq_bind.3 zmq_close.3 zmq_connect.3 zmq_init.3 \ +MAN1 = +MAN3 = zmq_bind.3 zmq_close.3 zmq_connect.3 zmq_device.3 zmq_init.3 \ zmq_msg_close.3 zmq_msg_copy.3 zmq_msg_data.3 zmq_msg_init.3 \ zmq_msg_init_data.3 zmq_msg_init_size.3 zmq_msg_move.3 zmq_msg_size.3 \ zmq_poll.3 zmq_recv.3 zmq_send.3 zmq_setsockopt.3 zmq_socket.3 \ @@ -225,15 +227,14 @@ MAN7 = zmq.7 zmq_tcp.7 zmq_pgm.7 zmq_epgm.7 zmq_inproc.7 zmq_ipc.7 \ MAN_DOC = $(MAN1) $(MAN3) $(MAN7) MAN_TXT = $(MAN1:%.1=%.txt) $(MAN3:%.3=%.txt) $(MAN7:%.7=%.txt) -MAN_HTML = $(MAN_TXT:%.txt=%.html) @INSTALL_MAN_TRUE@dist_man_MANS = $(MAN_DOC) EXTRA_DIST = asciidoc.conf $(MAN_TXT) $(am__append_1) MAINTAINERCLEANFILES = $(MAN_DOC) $(MAN_HTML) -@BUILD_DOC_TRUE@SUFFIXES = .html .txt .xml .1 .3 .7 +@BUILD_DOC_TRUE@SUFFIXES = .txt .xml .1 .3 .7 all: all-am .SUFFIXES: -.SUFFIXES: .html .txt .xml .1 .3 .7 +.SUFFIXES: .txt .xml .1 .3 .7 $(srcdir)/Makefile.in: $(srcdir)/Makefile.am $(am__configure_deps) @for dep in $?; do \ case '$(am__configure_deps)' in \ @@ -270,44 +271,6 @@ mostlyclean-libtool: clean-libtool: -rm -rf .libs _libs -install-man1: $(dist_man_MANS) - @$(NORMAL_INSTALL) - test -z "$(man1dir)" || $(MKDIR_P) "$(DESTDIR)$(man1dir)" - @list=''; test -n "$(man1dir)" || exit 0; \ - { for i in $$list; do echo "$$i"; done; \ - l2='$(dist_man_MANS)'; for i in $$l2; do echo "$$i"; done | \ - sed -n '/\.1[a-z]*$$/p'; \ - } | while read p; do \ - if test -f $$p; then d=; else d="$(srcdir)/"; fi; \ - echo "$$d$$p"; echo "$$p"; \ - done | \ - sed -e 'n;s,.*/,,;p;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \ - -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,' | \ - sed 'N;N;s,\n, ,g' | { \ - list=; while read file base inst; do \ - if test "$$base" = "$$inst"; then list="$$list $$file"; else \ - echo " $(INSTALL_DATA) '$$file' '$(DESTDIR)$(man1dir)/$$inst'"; \ - $(INSTALL_DATA) "$$file" "$(DESTDIR)$(man1dir)/$$inst" || exit $$?; \ - fi; \ - done; \ - for i in $$list; do echo "$$i"; done | $(am__base_list) | \ - while read files; do \ - test -z "$$files" || { \ - echo " $(INSTALL_DATA) $$files '$(DESTDIR)$(man1dir)'"; \ - $(INSTALL_DATA) $$files "$(DESTDIR)$(man1dir)" || exit $$?; }; \ - done; } - -uninstall-man1: - @$(NORMAL_UNINSTALL) - @list=''; test -n "$(man1dir)" || exit 0; \ - files=`{ for i in $$list; do echo "$$i"; done; \ - l2='$(dist_man_MANS)'; for i in $$l2; do echo "$$i"; done | \ - sed -n '/\.1[a-z]*$$/p'; \ - } | sed -e 's,.*/,,;h;s,.*\.,,;s,^[^1][0-9a-z]*$$,1,;x' \ - -e 's,\.[0-9a-z]*$$,,;$(transform);G;s,\n,.,'`; \ - test -z "$$files" || { \ - echo " ( cd '$(DESTDIR)$(man1dir)' && rm -f" $$files ")"; \ - cd "$(DESTDIR)$(man1dir)" && rm -f $$files; } install-man3: $(dist_man_MANS) @$(NORMAL_INSTALL) test -z "$(man3dir)" || $(MKDIR_P) "$(DESTDIR)$(man3dir)" @@ -441,7 +404,7 @@ check-am: all-am check: check-am all-am: Makefile $(MANS) installdirs: - for dir in "$(DESTDIR)$(man1dir)" "$(DESTDIR)$(man3dir)" "$(DESTDIR)$(man7dir)"; do \ + for dir in "$(DESTDIR)$(man3dir)" "$(DESTDIR)$(man7dir)"; do \ test -z "$$dir" || $(MKDIR_P) "$$dir"; \ done install: install-am @@ -506,7 +469,7 @@ install-info: install-info-am install-info-am: -install-man: install-man1 install-man3 install-man7 +install-man: install-man3 install-man7 install-pdf: install-pdf-am @@ -536,7 +499,7 @@ ps-am: uninstall-am: uninstall-man -uninstall-man: uninstall-man1 uninstall-man3 uninstall-man7 +uninstall-man: uninstall-man3 uninstall-man7 .MAKE: install-am install-strip @@ -546,30 +509,27 @@ uninstall-man: uninstall-man1 uninstall-man3 uninstall-man7 install-am install-data install-data-am install-dvi \ install-dvi-am install-exec install-exec-am install-html \ install-html-am install-info install-info-am install-man \ - install-man1 install-man3 install-man7 install-pdf \ - install-pdf-am install-ps install-ps-am install-strip \ - installcheck installcheck-am installdirs maintainer-clean \ + install-man3 install-man7 install-pdf install-pdf-am \ + install-ps install-ps-am install-strip installcheck \ + installcheck-am installdirs maintainer-clean \ maintainer-clean-generic mostlyclean mostlyclean-generic \ mostlyclean-libtool pdf pdf-am ps ps-am uninstall uninstall-am \ - uninstall-man uninstall-man1 uninstall-man3 uninstall-man7 + uninstall-man uninstall-man3 uninstall-man7 dist-hook : $(MAN_DOC) $(MAN_HTML) -@BUILD_DOC_TRUE@.txt.html: -@BUILD_DOC_TRUE@ asciidoc -d manpage -b xhtml11 -f asciidoc.conf \ -@BUILD_DOC_TRUE@ -azmq_version=@PACKAGE_VERSION@ $< @BUILD_DOC_TRUE@.txt.xml: -@BUILD_DOC_TRUE@ asciidoc -d manpage -b docbook -f asciidoc.conf \ +@BUILD_DOC_TRUE@ $(AM_V_GEN)$(ASCIIDOC) -d manpage -b docbook -f asciidoc.conf \ @BUILD_DOC_TRUE@ -azmq_version=@PACKAGE_VERSION@ $< @BUILD_DOC_TRUE@.xml.1: -@BUILD_DOC_TRUE@ xmlto man $< +@BUILD_DOC_TRUE@ $(AM_V_GEN)$(XMLTO) man $< @BUILD_DOC_TRUE@.xml.3: -@BUILD_DOC_TRUE@ xmlto man $< +@BUILD_DOC_TRUE@ $(AM_V_GEN)$(XMLTO) man $< @BUILD_DOC_TRUE@.xml.7: -@BUILD_DOC_TRUE@ xmlto man $< +@BUILD_DOC_TRUE@ $(AM_V_GEN)$(XMLTO) man $< @BUILD_DOC_TRUE@zmq_epgm.7: zmq_pgm.7 -@BUILD_DOC_TRUE@ cp zmq_pgm.7 $@ +@BUILD_DOC_TRUE@ $(AM_V_GEN)cp zmq_pgm.7 $@ # Tell versions [3.59,3.63) of GNU make to not export all variables. # Otherwise a system limit (for SysV at least) may be exceeded. diff --git a/doc/zmq.7 b/doc/zmq.7 index 9b1e430..61345fb 100644 --- a/doc/zmq.7 +++ b/doc/zmq.7 @@ -2,12 +2,12 @@ .\" Title: zmq .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ" "7" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ" "7" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -63,7 +63,9 @@ Terminate 0MQ context \fBThread safety\fR .RS 4 .sp -A 0MQ \fIcontext\fR is thread safe and may be shared among as many application threads as necessary, without any additional locking required on the part of the caller\&. Each 0MQ socket belonging to a particular \fIcontext\fR may only be used by \fBthe thread that created it\fR using \fIzmq_socket()\fR\&. +A 0MQ \fIcontext\fR is thread safe and may be shared among as many application threads as necessary, without any additional locking required on the part of the caller\&. +.sp +Individual 0MQ \fIsockets\fR are \fInot\fR thread safe except in the case where full memory barriers are issued when migrating a socket from one thread to another\&. In practice this means applications can create a socket in one thread with \fIzmq_socket()\fR and then pass it to a \fInewly created\fR thread as part of thread initialization, for example via a structure passed as an argument to \fIpthread_create()\fR\&. .RE .sp .it 1 an-trap @@ -183,27 +185,9 @@ Local in\-process (inter\-thread) communication transport .RE .SS "Devices" .sp -Apart from the 0MQ library the 0MQ distribution includes \fIdevices\fR which are building blocks intended to serve as intermediate nodes in complex messaging topologies\&. +0MQ provides \fIdevices\fR, which are building blocks that act as intermediate nodes in complex messaging topologies\&. Devices can act as brokers that other nodes connect to, proxies that connect through to other nodes, or any mix of these two models\&. .sp -The following devices are provided: -.PP -Forwarder device for request\-response messaging -.RS 4 - -\fBzmq_queue\fR(1) -.RE -.PP -Forwarder device for publish\-subscribe messaging -.RS 4 - -\fBzmq_forwarder\fR(1) -.RE -.PP -Streamer device for parallelized pipeline messaging -.RS 4 - -\fBzmq_streamer\fR(1) -.RE +You can start a device in an application thread, see \fBzmq_device\fR(3)\&. .SH "ERROR HANDLING" .sp The 0MQ library functions handle errors using the standard conventions found on POSIX systems\&. Generally, this means that upon failure a 0MQ library function shall return either a NULL value (if returning a pointer) or a negative value (if returning an integer), and the actual error code shall be stored in the \fIerrno\fR variable\&. @@ -231,7 +215,7 @@ The 0MQ distribution includes a C++ language binding, which is documented separa Other language bindings (Python, Ruby, Java and more) are provided by members of the 0MQ community and pointers can be found on the 0MQ website\&. .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "RESOURCES" .sp Main web site: \m[blue]\fBhttp://www\&.zeromq\&.org/\fR\m[] diff --git a/doc/zmq.html b/doc/zmq.html deleted file mode 100644 index bbb90ec..0000000 --- a/doc/zmq.html +++ /dev/null @@ -1,866 +0,0 @@ - - - - - -zmq(7) - - - - - -
-

SYNOPSIS

-
-

#include <zmq.h>

-

cc [flags] files -lzmq [libraries]

-
-

DESCRIPTION

-
-

The ØMQ lightweight messaging kernel is a library which extends the standard -socket interfaces with features traditionally provided by specialised -messaging middleware products. ØMQ sockets provide an abstraction of -asynchronous message queues, multiple messaging patterns, message -filtering (subscriptions), seamless access to multiple transport protocols -and more.

-

This documentation presents an overview of ØMQ concepts, describes how ØMQ -abstracts standard sockets and provides a reference manual for the functions -provided by the ØMQ library.

-

Context

-

Before using any ØMQ library functions the caller must initialise a ØMQ -context using zmq_init(). The following functions are provided to handle -initialisation and termination of a context:

-
-
-Initialise ØMQ context -
-
-

- zmq_init(3) -

-
-
-Terminate ØMQ context -
-
-

- zmq_term(3) -

-
-
-

Thread safety

-

A ØMQ context is thread safe and may be shared among as many application -threads as necessary, without any additional locking required on the part of the -caller. Each ØMQ socket belonging to a particular context may only be used -by the thread that created it using zmq_socket().

-

Multiple contexts

-

Multiple contexts may coexist within a single application. Thus, an -application can use ØMQ directly and at the same time make use of any number of -additional libraries or components which themselves make use of ØMQ as long as -the above guidelines regarding thread safety are adhered to.

-

Messages

-

A ØMQ message is a discrete unit of data passed between applications or -components of the same application. ØMQ messages have no internal structure and -from the point of view of ØMQ itself they are considered to be opaque binary -data.

-

The following functions are provided to work with messages:

-
-
-Initialise a message -
-
-

- zmq_msg_init(3) - zmq_msg_init_size(3) - zmq_msg_init_data(3) -

-
-
-Release a message -
-
-

- zmq_msg_close(3) -

-
-
-Access message content -
-
-

- zmq_msg_data(3) - zmq_msg_size(3) -

-
-
-Message manipulation -
-
-

- zmq_msg_copy(3) - zmq_msg_move(3) -

-
-
-

Sockets

-

ØMQ sockets present an abstraction of a asynchronous message queue, with the -exact queueing semantics depending on the socket type in use. See -zmq_socket(3) for the socket types provided.

-

The following functions are provided to work with sockets:

-
-
-Creating a socket -
-
-

- zmq_socket(3) -

-
-
-Closing a socket -
-
-

- zmq_close(3) -

-
-
-Manipulating socket options -
-
-

- zmq_getsockopt(3) - zmq_setsockopt(3) -

-
-
-Establishing a message flow -
-
-

- zmq_bind(3) - zmq_connect(3) -

-
-
-Sending and receiving messages -
-
-

- zmq_send(3) - zmq_recv(3) -

-
-
-
Input/output multiplexing

ØMQ provides a mechanism for applications to multiplex input/output events over -a set containing both ØMQ sockets and standard sockets. This mechanism mirrors -the standard poll() system call, and is described in detail in -zmq_poll(3).

-

Transports

-

A ØMQ socket can use multiple different underlying transport mechanisms. -Each transport mechanism is suited to a particular purpose and has its own -advantages and drawbacks.

-

The following transport mechanisms are provided:

-
-
-Unicast transport using TCP -
-
-

- zmq_tcp(7) -

-
-
-Reliable multicast transport using PGM -
-
-

- zmq_pgm(7) -

-
-
-Local inter-process communication transport -
-
-

- zmq_ipc(7) -

-
-
-Local in-process (inter-thread) communication transport -
-
-

- zmq_inproc(7) -

-
-
-

Devices

-

Apart from the ØMQ library the ØMQ distribution includes devices which are -building blocks intended to serve as intermediate nodes in complex messaging -topologies.

-

The following devices are provided:

-
-
-Forwarder device for request-response messaging -
-
-

- zmq_queue(1) -

-
-
-Forwarder device for publish-subscribe messaging -
-
-

- zmq_forwarder(1) -

-
-
-Streamer device for parallelized pipeline messaging -
-
-

- zmq_streamer(1) -

-
-
-
-

ERROR HANDLING

-
-

The ØMQ library functions handle errors using the standard conventions found on -POSIX systems. Generally, this means that upon failure a ØMQ library function -shall return either a NULL value (if returning a pointer) or a negative value -(if returning an integer), and the actual error code shall be stored in the -errno variable.

-

On non-POSIX systems some users may experience issues with retrieving the -correct value of the errno variable. The zmq_errno() function is provided -to assist in these cases; for details refer to zmq_errno(3).

-

The zmq_strerror() function is provided to translate ØMQ-specific error codes -into error message strings; for details refer to zmq_strerror(3).

-
-

MISCELLANEOUS

-
-

The following miscellaneous functions are provided:

-
-
-Report ØMQ library version -
-
-

- zmq_version(3) -

-
-
-
-

LANGUAGE BINDINGS

-
-

The ØMQ library provides interfaces suitable for calling from programs in any -language; this documentation documents those interfaces as they would be used -by C programmers. The intent is that programmers using ØMQ from other languages -shall refer to this documentation alongside any documentation provided by the -vendor of their language binding.

-

C++ language binding

-

The ØMQ distribution includes a C++ language binding, which is documented -separately in zmq_cpp(7).

-

Other language bindings

-

Other language bindings (Python, Ruby, Java and more) are provided by members -of the ØMQ community and pointers can be found on the ØMQ website.

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-

RESOURCES

-
-

Main web site: http://www.zeromq.org/

-

Report bugs to the ØMQ development mailing list: <zeromq-dev@lists.zeromq.org>

-
-

COPYING

-
-

Free use of this software is granted under the terms of the GNU Lesser General -Public License (LGPL). For details see the files COPYING and COPYING.LESSER -included with the ØMQ distribution.

-
-
-
- - - diff --git a/doc/zmq.txt b/doc/zmq.txt index 06658c9..16a5d30 100644 --- a/doc/zmq.txt +++ b/doc/zmq.txt @@ -44,9 +44,15 @@ Terminate 0MQ context:: Thread safety ^^^^^^^^^^^^^ A 0MQ 'context' is thread safe and may be shared among as many application -threads as necessary, without any additional locking required on the part of the -caller. Each 0MQ socket belonging to a particular 'context' may only be used -by *the thread that created it* using _zmq_socket()_. +threads as necessary, without any additional locking required on the part of +the caller. + +Individual 0MQ 'sockets' are _not_ thread safe except in the case where full +memory barriers are issued when migrating a socket from one thread to another. +In practice this means applications can create a socket in one thread with +_zmq_socket()_ and then pass it to a _newly created_ thread as part of thread +initialization, for example via a structure passed as an argument to +_pthread_create()_. Multiple contexts @@ -139,20 +145,12 @@ Local in-process (inter-thread) communication transport:: Devices ~~~~~~~ -Apart from the 0MQ library the 0MQ distribution includes 'devices' which are -building blocks intended to serve as intermediate nodes in complex messaging -topologies. - -The following devices are provided: - -Forwarder device for request-response messaging:: - linkzmq:zmq_queue[1] - -Forwarder device for publish-subscribe messaging:: - linkzmq:zmq_forwarder[1] +0MQ provides 'devices', which are building blocks that act as intermediate +nodes in complex messaging topologies. Devices can act as brokers that other +nodes connect to, proxies that connect through to other nodes, or any mix of +these two models. -Streamer device for parallelized pipeline messaging:: - linkzmq:zmq_streamer[1] +You can start a device in an application thread, see linkzmq:zmq_device[3]. ERROR HANDLING @@ -202,7 +200,7 @@ of the 0MQ community and pointers can be found on the 0MQ website. AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_bind.3 b/doc/zmq_bind.3 index c9e1e53..f4a637a 100644 --- a/doc/zmq_bind.3 +++ b/doc/zmq_bind.3 @@ -2,12 +2,12 @@ .\" Title: zmq_bind .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_BIND" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_BIND" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -120,6 +120,11 @@ The provided \fIsocket\fR was not valid (NULL)\&. .RE +.PP +\fBEMTHREAD\fR +.RS 4 +No I/O thread is available to accomplish the task\&. +.RE .SH "EXAMPLE" .PP \fBBinding a publisher socket to an in-process and a TCP transport\fR. @@ -147,7 +152,7 @@ assert (rc == 0); \fBzmq_connect\fR(3) \fBzmq_socket\fR(3) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_bind.html b/doc/zmq_bind.html deleted file mode 100644 index 72d37dc..0000000 --- a/doc/zmq_bind.html +++ /dev/null @@ -1,738 +0,0 @@ - - - - - -zmq_bind(3) - - - - - -
-

SYNOPSIS

-
-

int zmq_bind (void *socket, const char *endpoint);

-
-

DESCRIPTION

-
-

The zmq_bind() function shall create an endpoint for accepting connections -and bind it to the socket referenced by the socket argument.

-

The endpoint argument is a string consisting of two parts as follows: -transport://address. The transport part specifies the underlying -transport protocol to use. The meaning of the address part is specific to -the underlying transport protocol selected.

-

The following transports are defined:

-
-
-inproc -
-
-

-local in-process (inter-thread) communication transport, see zmq_inproc(7) -

-
-
-ipc -
-
-

-local inter-process communication transport, see zmq_ipc(7) -

-
-
-tcp -
-
-

-unicast transport using TCP, see zmq_tcp(7) -

-
-
-pgm, epgm -
-
-

-reliable multicast transport using PGM, see zmq_pgm(7) -

-
-
-

With the exception of ZMQ_PAIR sockets, a single socket may be connected to -multiple endpoints using zmq_connect(), while simultaneously accepting -incoming connections from multiple endpoints bound to the socket using -zmq_bind(). Refer to zmq_socket(3) for a description of the exact -semantics involved when connecting or binding a socket to multiple endpoints.

-
-

RETURN VALUE

-
-

The zmq_bind() function shall return zero if successful. Otherwise it shall -return -1 and set errno to one of the values defined below.

-
-

ERRORS

-
-
-
-EPROTONOSUPPORT -
-
-

-The requested transport protocol is not supported. -

-
-
-ENOCOMPATPROTO -
-
-

-The requested transport protocol is not compatible with the socket type. -

-
-
-EADDRINUSE -
-
-

-The requested address is already in use. -

-
-
-EADDRNOTAVAIL -
-
-

-The requested address was not local. -

-
-
-ENODEV -
-
-

-The requested address specifies a nonexistent interface. -

-
-
-ETERM -
-
-

-The ØMQ context associated with the specified socket was terminated. -

-
-
-EFAULT -
-
-

-The provided socket was not valid (NULL). -

-
-
-
-

EXAMPLE

-
-
-
Binding a publisher socket to an in-process and a TCP transport
-
-
/* Create a ZMQ_PUB socket */
-void *socket = zmq_socket (context, ZMQ_PUB);
-assert (socket);
-/* Bind it to a in-process transport with the address 'my_publisher' */
-int rc = zmq_bind (socket, "inproc://my_publisher");
-assert (rc == 0);
-/* Bind it to a TCP transport on port 5555 of the 'eth0' interface */
-rc = zmq_bind (socket, "tcp://eth0:5555");
-assert (rc == 0);
-
-
-

SEE ALSO

-
-

zmq_connect(3) -zmq_socket(3) -zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_bind.txt b/doc/zmq_bind.txt index 7aa5a0b..6492d9e 100644 --- a/doc/zmq_bind.txt +++ b/doc/zmq_bind.txt @@ -58,6 +58,8 @@ The requested 'address' specifies a nonexistent interface. The 0MQ 'context' associated with the specified 'socket' was terminated. *EFAULT*:: The provided 'socket' was not valid (NULL). +*EMTHREAD*:: +No I/O thread is available to accomplish the task. EXAMPLE @@ -85,5 +87,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_close.3 b/doc/zmq_close.3 index 2122caf..231ae96 100644 --- a/doc/zmq_close.3 +++ b/doc/zmq_close.3 @@ -2,12 +2,12 @@ .\" Title: zmq_close .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_CLOSE" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_CLOSE" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -34,7 +34,23 @@ zmq_close \- close 0MQ socket \fBint zmq_close (void \fR\fB\fI*socket\fR\fR\fB);\fR .SH "DESCRIPTION" .sp -The \fIzmq_close()\fR function shall destroy the socket referenced by the \fIsocket\fR argument\&. All active connections on the socket shall be terminated and resources associated with the socket shall be released\&. Any outstanding messages sent with \fIzmq_send()\fR but not yet physically sent to the network shall be dropped\&. Likewise, any outstanding messages physically received from the network but not yet received by the application with \fIzmq_recv()\fR shall also be dropped\&. +The \fIzmq_close()\fR function shall destroy the socket referenced by the \fIsocket\fR argument\&. Any outstanding messages physically received from the network but not yet received by the application with \fIzmq_recv()\fR shall be discarded\&. The behaviour for discarding messages sent by the application with \fIzmq_send()\fR but not yet physically transferred to the network depends on the value of the \fIZMQ_LINGER\fR socket option for the specified \fIsocket\fR\&. +.if n \{\ +.sp +.\} +.RS 4 +.it 1 an-trap +.nr an-no-space-flag 1 +.nr an-break-flag 1 +.br +.ps +1 +\fBNote\fR +.ps -1 +.br +.sp +The default setting of \fIZMQ_LINGER\fR does not discard unsent messages; this behaviour may cause the application to block when calling \fIzmq_term()\fR\&. For details refer to \fBzmq_setsockopt\fR(3) and \fBzmq_term\fR(3)\&. +.sp .5v +.RE .SH "RETURN VALUE" .sp The \fIzmq_close()\fR function shall return zero if successful\&. Otherwise it shall return \-1 and set \fIerrno\fR to one of the values defined below\&. @@ -48,10 +64,10 @@ was not valid (NULL)\&. .RE .SH "SEE ALSO" .sp -\fBzmq_socket\fR(3) \fBzmq_term\fR(3) \fBzmq\fR(7) +\fBzmq_socket\fR(3) \fBzmq_term\fR(3) \fBzmq_setsockopt\fR(3) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_close.html b/doc/zmq_close.html deleted file mode 100644 index bfb24af..0000000 --- a/doc/zmq_close.html +++ /dev/null @@ -1,635 +0,0 @@ - - - - - -zmq_close(3) - - - - - -
-

SYNOPSIS

-
-

int zmq_close (void *socket);

-
-

DESCRIPTION

-
-

The zmq_close() function shall destroy the socket referenced by the socket -argument. All active connections on the socket shall be terminated and -resources associated with the socket shall be released. Any outstanding -messages sent with zmq_send() but not yet physically sent to the network -shall be dropped. Likewise, any outstanding messages physically received from -the network but not yet received by the application with zmq_recv() shall -also be dropped.

-
-

RETURN VALUE

-
-

The zmq_close() function shall return zero if successful. Otherwise it shall -return -1 and set errno to one of the values defined below.

-
-

ERRORS

-
-
-
-EFAULT -
-
-

-The provided socket was not valid (NULL). -

-
-
-
-

SEE ALSO

-
-

zmq_socket(3) -zmq_term(3) -zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_close.txt b/doc/zmq_close.txt index e903437..89f9745 100644 --- a/doc/zmq_close.txt +++ b/doc/zmq_close.txt @@ -15,12 +15,15 @@ SYNOPSIS DESCRIPTION ----------- The _zmq_close()_ function shall destroy the socket referenced by the 'socket' -argument. All active connections on the socket shall be terminated and -resources associated with the socket shall be released. Any outstanding -messages sent with _zmq_send()_ but not yet physically sent to the network -shall be dropped. Likewise, any outstanding messages physically received from -the network but not yet received by the application with _zmq_recv()_ shall -also be dropped. +argument. Any outstanding messages physically received from the network but not +yet received by the application with _zmq_recv()_ shall be discarded. The +behaviour for discarding messages sent by the application with _zmq_send()_ but +not yet physically transferred to the network depends on the value of the +_ZMQ_LINGER_ socket option for the specified 'socket'. + +NOTE: The default setting of _ZMQ_LINGER_ does not discard unsent messages; +this behaviour may cause the application to block when calling _zmq_term()_. +For details refer to linkzmq:zmq_setsockopt[3] and linkzmq:zmq_term[3]. RETURN VALUE @@ -39,10 +42,11 @@ SEE ALSO -------- linkzmq:zmq_socket[3] linkzmq:zmq_term[3] +linkzmq:zmq_setsockopt[3] linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_connect.3 b/doc/zmq_connect.3 index 98be1e6..5305f76 100644 --- a/doc/zmq_connect.3 +++ b/doc/zmq_connect.3 @@ -2,12 +2,12 @@ .\" Title: zmq_connect .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_CONNECT" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_CONNECT" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -115,6 +115,11 @@ The provided \fIsocket\fR was not valid (NULL)\&. .RE +.PP +\fBEMTHREAD\fR +.RS 4 +No I/O thread is available to accomplish the task\&. +.RE .SH "EXAMPLE" .PP \fBConnecting a subscriber socket to an in-process and a TCP transport\fR. @@ -142,7 +147,7 @@ assert (rc == 0); \fBzmq_bind\fR(3) \fBzmq_socket\fR(3) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_connect.html b/doc/zmq_connect.html deleted file mode 100644 index ea0069a..0000000 --- a/doc/zmq_connect.html +++ /dev/null @@ -1,724 +0,0 @@ - - - - - -zmq_connect(3) - - - - - -
-

SYNOPSIS

-
-

int zmq_connect (void *socket, const char *endpoint);

-
-

DESCRIPTION

-
-

The zmq_connect() function shall connect the socket referenced by the -socket argument to the endpoint specified by the endpoint argument.

-

The endpoint argument is a string consisting of two parts as follows: -transport://address. The transport part specifies the underlying -transport protocol to use. The meaning of the address part is specific to -the underlying transport protocol selected.

-

The following transports are defined:

-
-
-inproc -
-
-

-local in-process (inter-thread) communication transport, see zmq_inproc(7) -

-
-
-ipc -
-
-

-local inter-process communication transport, see zmq_ipc(7) -

-
-
-tcp -
-
-

-unicast transport using TCP, see zmq_tcp(7) -

-
-
-pgm, epgm -
-
-

-reliable multicast transport using PGM, see zmq_pgm(7) -

-
-
-

With the exception of ZMQ_PAIR sockets, a single socket may be connected to -multiple endpoints using zmq_connect(), while simultaneously accepting -incoming connections from multiple endpoints bound to the socket using -zmq_bind(). Refer to zmq_socket(3) for a description of the exact -semantics involved when connecting or binding a socket to multiple endpoints.

-
- - - -
-
Note
-		The connection will not be performed immediately but as needed by ØMQ. -Thus a successful invocation of zmq_connect() does not indicate that a -physical connection was or can actually be established.
-
-
-

RETURN VALUE

-
-

The zmq_connect() function shall return zero if successful. Otherwise it -shall return -1 and set errno to one of the values defined below.

-
-

ERRORS

-
-
-
-EPROTONOSUPPORT -
-
-

-The requested transport protocol is not supported. -

-
-
-ENOCOMPATPROTO -
-
-

-The requested transport protocol is not compatible with the socket type. -

-
-
-ETERM -
-
-

-The ØMQ context associated with the specified socket was terminated. -

-
-
-EFAULT -
-
-

-The provided socket was not valid (NULL). -

-
-
-
-

EXAMPLE

-
-
-
Connecting a subscriber socket to an in-process and a TCP transport
-
-
/* Create a ZMQ_SUB socket */
-void *socket = zmq_socket (context, ZMQ_SUB);
-assert (socket);
-/* Connect it to an in-process transport with the address 'my_publisher' */
-int rc = zmq_connect (socket, "inproc://my_publisher");
-assert (rc == 0);
-/* Connect it to the host server001, port 5555 using a TCP transport */
-rc = zmq_connect (socket, "tcp://server001:5555");
-assert (rc == 0);
-
-
-

SEE ALSO

-
-

zmq_bind(3) -zmq_socket(3) -zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_connect.txt b/doc/zmq_connect.txt index ffcf3b4..acd0e9d 100644 --- a/doc/zmq_connect.txt +++ b/doc/zmq_connect.txt @@ -56,6 +56,8 @@ The requested 'transport' protocol is not compatible with the socket type. The 0MQ 'context' associated with the specified 'socket' was terminated. *EFAULT*:: The provided 'socket' was not valid (NULL). +*EMTHREAD*:: +No I/O thread is available to accomplish the task. EXAMPLE @@ -83,5 +85,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_cpp.7 b/doc/zmq_cpp.7 index b657017..2b0494e 100644 --- a/doc/zmq_cpp.7 +++ b/doc/zmq_cpp.7 @@ -2,12 +2,12 @@ .\" Title: zmq_cpp .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_CPP" "7" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_CPP" "7" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -211,7 +211,7 @@ Maps to the \fIzmq_connect()\fR function, as described in \fBzmq_connect\fR(3)\& .RE .\} .sp -Maps to the \fIzmq_send()\fR function, as described in \fBzmq_send\fR(3)\&. +Maps to the \fIzmq_send()\fR function, as described in \fBzmq_send\fR(3)\&. Returns true if message is successfully sent, false if it is not\&. .sp .if n \{\ .RS 4 @@ -223,7 +223,7 @@ Maps to the \fIzmq_send()\fR function, as described in \fBzmq_send\fR(3)\&. .RE .\} .sp -Maps to the \fIzmq_recv()\fR function, as described in \fBzmq_recv\fR(3)\&. +Maps to the \fIzmq_recv()\fR function, as described in \fBzmq_recv\fR(3)\&. Returns true if message is successfully received, false if it is not\&. .RE .SS "Message" .sp @@ -396,7 +396,7 @@ s\&.send (msg); \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_cpp.html b/doc/zmq_cpp.html deleted file mode 100644 index 59b206e..0000000 --- a/doc/zmq_cpp.html +++ /dev/null @@ -1,763 +0,0 @@ - - - - - -zmq_cpp(7) - - - - - -
-

SYNOPSIS

-
-

#include <zmq.hpp>

-

c++ [flags] files -lzmq [libraries]

-
-

DESCRIPTION

-
-

This manual page describes how the ØMQ C++ language binding maps to the -underlying ØMQ C library functions.

-

All ØMQ constants defined by zmq.h are also available to the C++ language -binding.

-

The following classes are provided in the zmq namespace:

-

Context

-

The context_t class encapsulates functionality dealing with the -initialisation and termination of a ØMQ context.

-

Constructor

-
-
context_t::context_t(int io_threads)
-
-
-

Maps to the zmq_init() function, as described in zmq_init(3).

-

Destructor

-
-
context_t::~context_t(void)
-
-
-

Maps to the zmq_term() function, as described in zmq_term(3).

-

Methods

-

None.

-

Socket

-

The socket_t class encapsulates a ØMQ socket.

-

Constructor

-
-
socket_t::socket_t(context_t &context, int type)
-
-
-

Maps to the zmq_socket() function, as described in zmq_socket(3).

-

Destructor

-
-
socket_t::~socket_t(void)
-
-
-

Calls the zmq_close() function, as described in zmq_close(3).

-

Methods

-
-
void socket_t::getsockopt(int option_name, void *option_value, size_t -*option_len)
-
-
-

Maps to the zmq_getsockopt() function, as described in -zmq_getsockopt(3).

-
-
void socket_t::setsockopt(int option_name, const void *option_value, size_t -option_len)
-
-
-

Maps to the zmq_setsockopt() function, as described in -zmq_setsockopt(3).

-
-
void socket_t::bind(const char *endpoint)
-
-
-

Maps to the zmq_bind() function, as described in zmq_bind(3).

-
-
void socket_t::connect(const char *endpoint)
-
-
-

Maps to the zmq_connect() function, as described in zmq_connect(3).

-
-
bool socket_t::send(message_t &msg, int flags = 0)
-
-
-

Maps to the zmq_send() function, as described in zmq_send(3).

-
-
bool socket_t::recv(message_t *msg, int flags = 0)
-
-
-

Maps to the zmq_recv() function, as described in zmq_recv(3).

-

Message

-

The zmq::message_t class encapsulates the zmq_msg_t structure and -functions to construct, destruct and manipulate ØMQ messages.

-

Constructor

-
-
message_t::message_t(void) -message_t::message_t(size_t size) -message_t::message_t(void *data, size_t size, free_fn *ffn)
-
-
-

These map to the zmq_msg_init(), zmq_msg_init_size() and -zmq_msg_init_data() functions, described in zmq_msg_init(3), -zmq_msg_init_size(3) and zmq_msg_init_data(3) respectively.

-

Destructor

-
-
message_t::~message_t(void)
-
-
-

Calls the zmq_msg_close() function, as described in zmq_msg_close(3).

-

Methods

-
-
void *message_t::data (void)
-
-
-

Maps to the zmq_msg_data() function, as described in zmq_msg_data(3).

-
-
size_t message_t::size (void)
-
-
-

Maps to the zmq_msg_size() function, as described in zmq_msg_size(3).

-
-
void message_t::copy (message_t *src)
-
-
-

Maps to the zmq_msg_copy() function, as described in zmq_msg_copy(3).

-
-
void message_t::move (message_t *src)
-
-
-

Maps to the zmq_msg_move() function, as described in zmq_msg_move(3).

-
-
message_t::rebuild(void) -message_t::rebuild(size_t size) -message_t::rebuild(void *data, size_t size, free_fn *ffn)
-
-
-

Equivalent to calling the zmq_msg_close() function followed by the -corresponding zmq_msg_init() function.

-

Input/output multiplexing

-
-
int poll (zmq_pollitem_t *items, int nitems, long timeout = -1)
-
-
-

The poll() function is a namespaced equivalent of the zmq_poll() function, -as described in zmq_poll(3).

-
- - - -
-
Note
-		To obtain a ØMQ socket for use in a zmq_pollitem_t structure, you -should cast an instance of the socket_t class to (void *).
-
-
-

ERROR HANDLING

-
-

All errors reported by the underlying ØMQ C library functions are automatically -converted to exceptions by the C++ language binding. The zmq::error_t class -is derived from the std::exception class and uses the zmq_strerror() -function to convert the error code to human-readable string.

-
-

EXAMPLE

-
-
-
-
zmq::context_t ctx (1);
-zmq::socket_t s (ctx, ZMQ_PUB);
-s.connect ("tcp://192.168.0.115:5555");
-zmq::message_t msg (100);
-memset (msg.data (), 0, 100);
-s.send (msg);
-
-
-

SEE ALSO

-
-

zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_cpp.txt b/doc/zmq_cpp.txt index d43ff62..cd5cdc9 100644 --- a/doc/zmq_cpp.txt +++ b/doc/zmq_cpp.txt @@ -102,11 +102,13 @@ Maps to the _zmq_connect()_ function, as described in linkzmq:zmq_connect[3]. *bool socket_t::send(message_t '&msg', int 'flags' = 0)* Maps to the _zmq_send()_ function, as described in linkzmq:zmq_send[3]. +Returns true if message is successfully sent, false if it is not. [verse] *bool socket_t::recv(message_t '*msg', int 'flags' = 0)* Maps to the _zmq_recv()_ function, as described in linkzmq:zmq_recv[3]. +Returns true if message is successfully received, false if it is not. Message @@ -206,5 +208,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_device.3 b/doc/zmq_device.3 new file mode 100644 index 0000000..e19c800 --- /dev/null +++ b/doc/zmq_device.3 @@ -0,0 +1,140 @@ +'\" t +.\" Title: zmq_device +.\" Author: [see the "AUTHORS" section] +.\" Generator: DocBook XSL Stylesheets v1.75.2 +.\" Date: 03/15/2011 +.\" Manual: 0MQ Manual +.\" Source: 0MQ 2.1.3 +.\" Language: English +.\" +.TH "ZMQ_DEVICE" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" +.\" ----------------------------------------------------------------- +.\" * Define some portability stuff +.\" ----------------------------------------------------------------- +.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +.\" http://bugs.debian.org/507673 +.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html +.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +.ie \n(.g .ds Aq \(aq +.el .ds Aq ' +.\" ----------------------------------------------------------------- +.\" * set default formatting +.\" ----------------------------------------------------------------- +.\" disable hyphenation +.nh +.\" disable justification (adjust text to left margin only) +.ad l +.\" ----------------------------------------------------------------- +.\" * MAIN CONTENT STARTS HERE * +.\" ----------------------------------------------------------------- +.SH "NAME" +zmq_device \- start built\-in 0MQ device +.SH "SYNOPSIS" +.sp +\fBint zmq_device (int \fR\fB\fIdevice\fR\fR\fB, const void \fR\fB\fI*frontend\fR\fR\fB, const void \fR\fB\fI*backend\fR\fR\fB);\fR +.SH "DESCRIPTION" +.sp +The \fIzmq_device()\fR function starts a built\-in 0MQ device\&. The \fIdevice\fR argument is one of: +.PP +\fIZMQ_QUEUE\fR +.RS 4 +starts a queue device +.RE +.PP +\fIZMQ_FORWARDER\fR +.RS 4 +starts a forwarder device +.RE +.PP +\fIZMQ_STREAMER\fR +.RS 4 +starts a streamer device +.RE +.sp +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\&. +.sp +Before calling \fIzmq_device()\fR you must set any socket options, and connect or bind both frontend and backend sockets\&. The two conventional device models are: +.PP +\fBproxy\fR +.RS 4 +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)\&. +.RE +.PP +\fBbroker\fR +.RS 4 +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)\&. +.RE +.sp +\fIzmq_device()\fR runs in the current thread and returns only if/when the current context is closed\&. +.SH "QUEUE DEVICE" +.sp +\fIZMQ_QUEUE\fR 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\&. +.sp +This device is part of the \fIrequest\-reply\fR pattern\&. The frontend speaks to clients and the backend speaks to services\&. You should use \fIZMQ_QUEUE\fR with a \fIZMQ_XREP\fR socket for the frontend and a \fIZMQ_XREQ\fR socket for the backend\&. Other combinations are not documented\&. +.sp +Refer to \fBzmq_socket\fR(3) for a description of these socket types\&. +.SH "FORWARDER DEVICE" +.sp +\fIZMQ_FORWARDER\fR 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\&. +.sp +This device is part of the \fIpublish\-subscribe\fR pattern\&. The frontend speaks to publishers and the backend speaks to subscribers\&. You should use \fIZMQ_FORWARDER\fR with a \fIZMQ_SUB\fR socket for the frontend and a \fIZMQ_PUB\fR socket for the backend\&. Other combinations are not documented\&. +.sp +Refer to \fBzmq_socket\fR(3) for a description of these socket types\&. +.SH "STREAMER DEVICE" +.sp +\fIZMQ_STREAMER\fR 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\&. +.sp +This device is part of the \fIpipeline\fR pattern\&. The frontend speaks to pushers and the backend speaks to pullers\&. You should use \fIZMQ_STREAMER\fR with a \fIZMQ_PULL\fR socket for the frontend and a \fIZMQ_PUSH\fR socket for the backend\&. Other combinations are not documented\&. +.sp +Refer to \fBzmq_socket\fR(3) for a description of these socket types\&. +.SH "RETURN VALUE" +.sp +The \fIzmq_device()\fR function always returns \-1 and \fIerrno\fR set to \fBETERM\fR (the 0MQ \fIcontext\fR associated with either of the specified sockets was terminated)\&. +.SH "EXAMPLE" +.PP +\fBCreating a queue broker\fR. +.sp +.if n \{\ +.RS 4 +.\} +.nf +// 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); +.fi +.if n \{\ +.RE +.\} +.sp +.SH "SEE ALSO" +.sp +\fBzmq_bind\fR(3) \fBzmq_connect\fR(3) \fBzmq_socket\fR(3) \fBzmq\fR(7) +.SH "AUTHORS" +.sp +This 0MQ manual page was written by Pieter Hintjens <\m[blue]\fBph@imatix\&.com\fR\m[]\&\s-2\u[1]\d\s+2> +.SH "RESOURCES" +.sp +Main web site: \m[blue]\fBhttp://www\&.zeromq\&.org/\fR\m[] +.sp +Report bugs to the 0MQ development mailing list: <\m[blue]\fBzeromq\-dev@lists\&.zeromq\&.org\fR\m[]\&\s-2\u[2]\d\s+2> +.SH "COPYING" +.sp +Free use of this software is granted under the terms of the GNU Lesser General Public License (LGPL)\&. For details see the files COPYING and COPYING\&.LESSER included with the 0MQ distribution\&. +.SH "NOTES" +.IP " 1." 4 +ph@imatix.com +.RS 4 +\%mailto:ph@imatix.com +.RE +.IP " 2." 4 +zeromq-dev@lists.zeromq.org +.RS 4 +\%mailto:zeromq-dev@lists.zeromq.org +.RE diff --git a/doc/zmq_device.txt b/doc/zmq_device.txt new file mode 100644 index 0000000..93e616d --- /dev/null +++ b/doc/zmq_device.txt @@ -0,0 +1,138 @@ +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 +------------ +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] + + +AUTHORS +------- +This 0MQ manual page was written by Pieter Hintjens + + +RESOURCES +--------- +Main web site: + +Report bugs to the 0MQ development mailing list: + + +COPYING +------- +Free use of this software is granted under the terms of the GNU Lesser General +Public License (LGPL). For details see the files `COPYING` and `COPYING.LESSER` +included with the 0MQ distribution. diff --git a/doc/zmq_epgm.7 b/doc/zmq_epgm.7 index 9135e1c..06cc456 100644 --- a/doc/zmq_epgm.7 +++ b/doc/zmq_epgm.7 @@ -2,12 +2,12 @@ .\" Title: zmq_pgm .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_PGM" "7" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_PGM" "7" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -38,7 +38,7 @@ PGM (Pragmatic General Multicast) is a protocol for reliable multicast transport .sp The \fIpgm\fR and \fIepgm\fR transports can only be used with the \fIZMQ_PUB\fR and \fIZMQ_SUB\fR socket types\&. .sp -Further, PGM sockets are rate limited by default and incur a performance penalty when used over a loopback interface\&. For details, refer to the \fIZMQ_RATE\fR, \fIZMQ_RECOVERY_IVL\fR and \fIZMQ_MCAST_LOOP\fR options documented in \fBzmq_setsockopt\fR(3)\&. +Further, PGM sockets are rate limited by default and incur a performance penalty when used over a loop\-back interface\&. For details, refer to the \fIZMQ_RATE\fR, \fIZMQ_RECOVERY_IVL\fR and \fIZMQ_MCAST_LOOP\fR options documented in \fBzmq_setsockopt\fR(3)\&. .if n \{\ .sp .\} @@ -105,7 +105,7 @@ Interface names are not standardised in any way and should be assumed to be arbi A \fImulticast address\fR is specified by an IPv4 multicast address in it\(cqs numeric representation\&. .SH "WIRE FORMAT" .sp -Consecutive PGM datagrams are interpreted by 0MQ as a single continous stream of data where 0MQ messages are not necessarily aligned with PGM datagram boundaries and a single 0MQ message may span several PGM datagrams\&. This stream of data consists of 0MQ messages encapsulated in \fIframes\fR as described in \fBzmq_tcp\fR(7)\&. +Consecutive PGM datagrams are interpreted by 0MQ as a single continuous stream of data where 0MQ messages are not necessarily aligned with PGM datagram boundaries and a single 0MQ message may span several PGM datagrams\&. This stream of data consists of 0MQ messages encapsulated in \fIframes\fR as described in \fBzmq_tcp\fR(7)\&. .SS "PGM datagram payload" .sp The following ABNF grammar represents the payload of a single PGM datagram as used by 0MQ: @@ -174,7 +174,7 @@ Third datagram payload .\} .nf /* Connecting to the multicast address 239\&.192\&.1\&.1, port 5555, */ -/* using the first ethernet network interface on Linux */ +/* using the first Ethernet network interface on Linux */ /* and the Encapsulated PGM protocol */ rc = zmq_connect(socket, "epgm://eth0;239\&.192\&.1\&.1:5555"); assert (rc == 0); @@ -193,7 +193,7 @@ assert (rc == 0); \fBzmq_connect\fR(3) \fBzmq_setsockopt\fR(3) \fBzmq_tcp\fR(7) \fBzmq_ipc\fR(7) \fBzmq_inproc\fR(7) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_epgm.html b/doc/zmq_epgm.html deleted file mode 100644 index 06a1b70..0000000 --- a/doc/zmq_epgm.html +++ /dev/null @@ -1,745 +0,0 @@ - - - - - -zmq_pgm(7) - - - - - -
-

SYNOPSIS

-
-

PGM (Pragmatic General Multicast) is a protocol for reliable multicast -transport of data over IP networks.

-
-

DESCRIPTION

-
-

ØMQ implements two variants of PGM, the standard protocol where PGM datagrams -are layered directly on top of IP datagrams as defined by RFC 3208 (the pgm -transport) and "Encapsulated PGM" where PGM datagrams are encapsulated inside -UDP datagrams (the epgm transport).

-

The pgm and epgm transports can only be used with the ZMQ_PUB and -ZMQ_SUB socket types.

-

Further, PGM sockets are rate limited by default and incur a performance -penalty when used over a loopback interface. For details, refer to the -ZMQ_RATE, ZMQ_RECOVERY_IVL and ZMQ_MCAST_LOOP options documented in -zmq_setsockopt(3).

-
- - - -
-
Caution
-		The pgm transport implementation requires access to raw IP sockets. -Additional privileges may be required on some operating systems for this -operation. Applications not requiring direct interoperability with other PGM -implementations are encouraged to use the epgm transport instead which does -not require any special privileges.
-
-
-

ADDRESSING

-
-

A ØMQ address string consists of two parts as follows: -transport://endpoint. The transport part specifies the underlying -transport protocol to use. For the standard PGM protocol, transport shall be -set to pgm. For the "Encapsulated PGM" protocol transport shall be set to -epgm. The meaning of the endpoint part for both the pgm and epgm -transport is defined below.

-

Connecting a socket

-

When connecting a socket to a peer address using zmq_connect() with the pgm -or epgm transport, the endpoint shall be interpreted as an interface -followed by a semicolon, followed by a multicast address, followed by a colon -and a port number.

-

An interface may be specified by either of the following:

-
    -
  • -

    -The interface name as defined by the operating system. -

    -
    • -
  • -

    -The primary IPv4 address assigned to the interface, in it’s numeric - representation. -

    -
    • -
-
- - - -
-
Note
-		Interface names are not standardised in any way and should be assumed to -be arbitrary and platform dependent. On Win32 platforms no short interface -names exist, thus only the primary IPv4 address may be used to specify an -interface.
-
-

A multicast address is specified by an IPv4 multicast address in it’s numeric -representation.

-
-

WIRE FORMAT

-
-

Consecutive PGM datagrams are interpreted by ØMQ as a single continous stream -of data where ØMQ messages are not necessarily aligned with PGM datagram -boundaries and a single ØMQ message may span several PGM datagrams. This stream -of data consists of ØMQ messages encapsulated in frames as described in -zmq_tcp(7).

-

PGM datagram payload

-

The following ABNF grammar represents the payload of a single PGM datagram as -used by ØMQ:

-
-
-
datagram               = (offset data)
-offset                 = 2OCTET
-data                   = *OCTET
-
-

In order for late joining consumers to be able to identify message boundaries, -each PGM datagram payload starts with a 16-bit unsigned integer in network byte -order specifying either the offset of the first message frame in the datagram -or containing the value 0xFFFF if the datagram contains solely an -intermediate part of a larger message.

-

The following diagram illustrates the layout of a single PGM datagram payload:

-
-
-
+------------------+----------------------+
-| offset (16 bits) |         data         |
-+------------------+----------------------+
-
-

The following diagram further illustrates how three example ØMQ frames are laid -out in consecutive PGM datagram payloads:

-
-
-
First datagram payload
-+--------------+-------------+---------------------+
-| Frame offset |   Frame 1   |   Frame 2, part 1   |
-|    0x0000    | (Message 1) | (Message 2, part 1) |
-+--------------+-------------+---------------------+
-
-Second datagram payload
-+--------------+---------------------+
-| Frame offset |   Frame 2, part 2   |
-| 0xFFFF       | (Message 2, part 2) |
-+--------------+---------------------+
-
-Third datagram payload
-+--------------+----------------------------+-------------+
-| Frame offset |   Frame 2, final 8 bytes   |   Frame 3   |
-| 0x0008       | (Message 2, final 8 bytes) | (Message 3) |
-+--------------+----------------------------+-------------+
-
-
-

EXAMPLE

-
-
-
Connecting a socket
-
-
/* Connecting to the multicast address 239.192.1.1, port 5555, */
-/* using the first ethernet network interface on Linux */
-/* and the Encapsulated PGM protocol */
-rc = zmq_connect(socket, "epgm://eth0;239.192.1.1:5555");
-assert (rc == 0);
-/* Connecting to the multicast address 239.192.1.1, port 5555, */
-/* using the network interface with the address 192.168.1.1 */
-/* and the standard PGM protocol */
-rc = zmq_connect(socket, "pgm://192.168.1.1;239.192.1.1:5555");
-assert (rc == 0);
-
-
-

SEE ALSO

-
-

zmq_connect(3) -zmq_setsockopt(3) -zmq_tcp(7) -zmq_ipc(7) -zmq_inproc(7) -zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_epgm.txt b/doc/zmq_epgm.txt index 4017db2..72ae24f 100644 --- a/doc/zmq_epgm.txt +++ b/doc/zmq_epgm.txt @@ -24,7 +24,7 @@ The 'pgm' and 'epgm' transports can only be used with the 'ZMQ_PUB' and 'ZMQ_SUB' socket types. Further, PGM sockets are rate limited by default and incur a performance -penalty when used over a loopback interface. For details, refer to the +penalty when used over a loop-back interface. For details, refer to the 'ZMQ_RATE', 'ZMQ_RECOVERY_IVL' and 'ZMQ_MCAST_LOOP' options documented in linkzmq:zmq_setsockopt[3]. @@ -69,7 +69,7 @@ representation. WIRE FORMAT ----------- -Consecutive PGM datagrams are interpreted by 0MQ as a single continous stream +Consecutive PGM datagrams are interpreted by 0MQ as a single continuous stream of data where 0MQ messages are not necessarily aligned with PGM datagram boundaries and a single 0MQ message may span several PGM datagrams. This stream of data consists of 0MQ messages encapsulated in 'frames' as described in @@ -130,7 +130,7 @@ EXAMPLE .Connecting a socket ---- /* Connecting to the multicast address 239.192.1.1, port 5555, */ -/* using the first ethernet network interface on Linux */ +/* using the first Ethernet network interface on Linux */ /* and the Encapsulated PGM protocol */ rc = zmq_connect(socket, "epgm://eth0;239.192.1.1:5555"); assert (rc == 0); @@ -153,5 +153,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_errno.3 b/doc/zmq_errno.3 index 7f3f4e6..9e9a688 100644 --- a/doc/zmq_errno.3 +++ b/doc/zmq_errno.3 @@ -2,12 +2,12 @@ .\" Title: zmq_errno .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_ERRNO" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_ERRNO" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -36,7 +36,7 @@ zmq_errno \- retrieve value of errno for the calling thread .sp The \fIzmq_errno()\fR function shall retrieve the value of the \fIerrno\fR variable for the calling thread\&. .sp -The \fIzmq_errno()\fR function is provided to assist users on non\-POSIX systems who are experiencing issues with retrieving the correct value of \fIerrno\fR directly\&. Specifically, users on Win32 systems whose application is using a different C runtime library from the C runtime library in use by 0MQ will need to use \fIzmq_errno()\fR for correct operation\&. +The \fIzmq_errno()\fR function is provided to assist users on non\-POSIX systems who are experiencing issues with retrieving the correct value of \fIerrno\fR directly\&. Specifically, users on Win32 systems whose application is using a different C run\-time library from the C run\-time library in use by 0MQ will need to use \fIzmq_errno()\fR for correct operation\&. .if n \{\ .sp .\} @@ -64,7 +64,7 @@ No errors are defined\&. \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_errno.html b/doc/zmq_errno.html deleted file mode 100644 index f983bd1..0000000 --- a/doc/zmq_errno.html +++ /dev/null @@ -1,634 +0,0 @@ - - - - - -zmq_errno(3) - - - - - -
-

SYNOPSIS

-
-

int zmq_errno (void);

-
-

DESCRIPTION

-
-

The zmq_errno() function shall retrieve the value of the errno variable for -the calling thread.

-

The zmq_errno() function is provided to assist users on non-POSIX systems who -are experiencing issues with retrieving the correct value of errno directly. -Specifically, users on Win32 systems whose application is using a different C -runtime library from the C runtime library in use by ØMQ will need to use -zmq_errno() for correct operation.

-
- - - -
-
Important
-		Users not experiencing issues with retrieving the correct value of -errno should not use this function and should instead access the errno -variable directly.
-
-
-

RETURN VALUE

-
-

The zmq_errno() function shall return the value of the errno variable for -the calling thread.

-
-

ERRORS

-
-

No errors are defined.

-
-

SEE ALSO

-
-

zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_errno.txt b/doc/zmq_errno.txt index 61939a5..f9cf6cb 100644 --- a/doc/zmq_errno.txt +++ b/doc/zmq_errno.txt @@ -20,7 +20,7 @@ the calling thread. The _zmq_errno()_ function is provided to assist users on non-POSIX systems who are experiencing issues with retrieving the correct value of 'errno' directly. Specifically, users on Win32 systems whose application is using a different C -runtime library from the C runtime library in use by 0MQ will need to use +run-time library from the C run-time library in use by 0MQ will need to use _zmq_errno()_ for correct operation. IMPORTANT: Users not experiencing issues with retrieving the correct value of @@ -46,5 +46,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_forwarder.1 b/doc/zmq_forwarder.1 deleted file mode 100644 index d0a6c39..0000000 --- a/doc/zmq_forwarder.1 +++ /dev/null @@ -1,57 +0,0 @@ -'\" t -.\" Title: zmq_forwarder -.\" Author: [see the "AUTHORS" section] -.\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 -.\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 -.\" Language: English -.\" -.TH "ZMQ_FORWARDER" "1" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" -.\" ----------------------------------------------------------------- -.\" * Define some portability stuff -.\" ----------------------------------------------------------------- -.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.\" http://bugs.debian.org/507673 -.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html -.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.ie \n(.g .ds Aq \(aq -.el .ds Aq ' -.\" ----------------------------------------------------------------- -.\" * set default formatting -.\" ----------------------------------------------------------------- -.\" disable hyphenation -.nh -.\" disable justification (adjust text to left margin only) -.ad l -.\" ----------------------------------------------------------------- -.\" * MAIN CONTENT STARTS HERE * -.\" ----------------------------------------------------------------- -.SH "NAME" -zmq_forwarder \- forwarding device for publish\-subscribe messaging -.SH "SYNOPSIS" -.sp -To be written\&. -.SH "DESCRIPTION" -.sp -To be written\&. -.SH "OPTIONS" -.sp -To be written\&. -.SH "SEE ALSO" -.sp -\fBzmq\fR(7) -.SH "AUTHORS" -.sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. -.SH "NOTES" -.IP " 1." 4 -sustrik@250bpm.com -.RS 4 -\%mailto:sustrik@250bpm.com -.RE -.IP " 2." 4 -mato@kotelna.sk -.RS 4 -\%mailto:mato@kotelna.sk -.RE diff --git a/doc/zmq_forwarder.html b/doc/zmq_forwarder.html deleted file mode 100644 index 704a8a6..0000000 --- a/doc/zmq_forwarder.html +++ /dev/null @@ -1,613 +0,0 @@ - - - - - -zmq_forwarder(1) - - - - - -
-

SYNOPSIS

-
-

To be written.

-
-

DESCRIPTION

-
-

To be written.

-
-

OPTIONS

-
-

To be written.

-
-

SEE ALSO

-
-

zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_forwarder.txt b/doc/zmq_forwarder.txt deleted file mode 100644 index b3325f2..0000000 --- a/doc/zmq_forwarder.txt +++ /dev/null @@ -1,33 +0,0 @@ -zmq_forwarder(1) -================ - - -NAME ----- -zmq_forwarder - forwarding device for publish-subscribe messaging - - -SYNOPSIS --------- -To be written. - - -DESCRIPTION ------------ -To be written. - - -OPTIONS -------- -To be written. - - -SEE ALSO --------- -linkzmq:zmq[7] - - -AUTHORS -------- -The 0MQ documentation was written by Martin Sustrik and -Martin Lucina . diff --git a/doc/zmq_getsockopt.3 b/doc/zmq_getsockopt.3 index d1ea10b..9ab4ec9 100644 --- a/doc/zmq_getsockopt.3 +++ b/doc/zmq_getsockopt.3 @@ -2,12 +2,12 @@ .\" Title: zmq_getsockopt .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_GETSOCKOPT" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_GETSOCKOPT" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -37,6 +37,45 @@ zmq_getsockopt \- get 0MQ socket options The \fIzmq_getsockopt()\fR function shall retrieve the value for the option specified by the \fIoption_name\fR argument for the 0MQ socket pointed to by the \fIsocket\fR argument, and store it in the buffer pointed to by the \fIoption_value\fR argument\&. The \fIoption_len\fR argument is the size in bytes of the buffer pointed to by \fIoption_value\fR; upon successful completion \fIzmq_getsockopt()\fR shall modify the \fIoption_len\fR argument to indicate the actual size of the option value stored in the buffer\&. .sp The following options can be retrieved with the \fIzmq_getsockopt()\fR function: +.SS "ZMQ_TYPE: Retrieve socket type" +.sp +The \fIZMQ_TYPE\fR option shall retrieve the socket type for the specified \fIsocket\fR\&. The socket type is specified at socket creation time and cannot be modified afterwards\&. +.TS +tab(:); +lt lt +lt lt +lt lt +lt lt. +T{ +.sp +Option value type +T}:T{ +.sp +int +T} +T{ +.sp +Option value unit +T}:T{ +.sp +N/A +T} +T{ +.sp +Default value +T}:T{ +.sp +N/A +T} +T{ +.sp +Applicable socket types +T}:T{ +.sp +all +T} +.TE +.sp 1 .SS "ZMQ_RCVMORE: More message parts to follow" .sp The \fIZMQ_RCVMORE\fR option shall return a boolean value indicating if the multi\-part message currently being read from the specified \fIsocket\fR has more message parts to follow\&. If there are no message parts to follow or if the message currently being read is not a multi\-part message a value of zero shall be returned\&. Otherwise, a value of 1 shall be returned\&. @@ -207,7 +246,7 @@ T} .sp 1 .SS "ZMQ_IDENTITY: Retrieve socket identity" .sp -The \fIZMQ_IDENTITY\fR option shall retrieve the identity of the specified \fIsocket\fR\&. Socket identity determines if existing 0MQ infastructure (\fImessage queues\fR, \fIforwarding devices\fR) shall be identified with a specific application and persist across multiple runs of the application\&. +The \fIZMQ_IDENTITY\fR option shall retrieve the identity of the specified \fIsocket\fR\&. Socket identity determines if existing 0MQ infrastructure (\fImessage queues\fR, \fIforwarding devices\fR) shall be identified with a specific application and persist across multiple runs of the application\&. .sp If the socket has no identity, each run of an application is completely separate from other runs\&. However, with identity set the socket shall re\-use any existing 0MQ infrastructure configured by the previous run(s)\&. Thus the application may receive messages that were sent in the meantime, \fImessage queue\fR limits shall be shared with previous run(s) and so on\&. .sp @@ -326,9 +365,50 @@ all, when using multicast transports T} .TE .sp 1 -.SS "ZMQ_MCAST_LOOP: Control multicast loopback" +.SS "ZMQ_RECOVERY_IVL_MSEC: Get multicast recovery interval in milliseconds" +.sp +The \fIZMQ_RECOVERY_IVL\(cq_MSEC option shall retrieve the recovery interval, in milliseconds, for multicast transports using the specified \*(Aqsocket\fR\&. The recovery interval determines the maximum time in seconds that a receiver can be absent from a multicast group before unrecoverable data loss will occur\&. .sp -The \fIZMQ_MCAST_LOOP\fR option controls whether data sent via multicast transports can also be received by the sending host via loopback\&. A value of zero indicates that the loopback functionality is disabled, while the default value of 1 indicates that the loopback functionality is enabled\&. Leaving multicast loopback enabled when it is not required can have a negative impact on performance\&. Where possible, disable \fIZMQ_MCAST_LOOP\fR in production environments\&. +For backward compatibility, the default value of \fIZMQ_RECOVERY_IVL_MSEC\fR is \-1 indicating that the recovery interval should be obtained from the \fIZMQ_RECOVERY_IVL\fR option\&. However, if the \fIZMQ_RECOVERY_IVL_MSEC\fR value is not zero, then it will take precedence, and be used\&. +.TS +tab(:); +lt lt +lt lt +lt lt +lt lt. +T{ +.sp +Option value type +T}:T{ +.sp +int64_t +T} +T{ +.sp +Option value unit +T}:T{ +.sp +milliseconds +T} +T{ +.sp +Default value +T}:T{ +.sp +\-1 +T} +T{ +.sp +Applicable socket types +T}:T{ +.sp +all, when using multicast transports +T} +.TE +.sp 1 +.SS "ZMQ_MCAST_LOOP: Control multicast loop\-back" +.sp +The \fIZMQ_MCAST_LOOP\fR option controls whether data sent via multicast transports can also be received by the sending host via loop\-back\&. A value of zero indicates that the loop\-back functionality is disabled, while the default value of 1 indicates that the loop\-back functionality is enabled\&. Leaving multicast loop\-back enabled when it is not required can have a negative impact on performance\&. Where possible, disable \fIZMQ_MCAST_LOOP\fR in production environments\&. .TS tab(:); lt lt @@ -443,6 +523,352 @@ all T} .TE .sp 1 +.SS "ZMQ_LINGER: Retrieve linger period for socket shutdown" +.sp +The \fIZMQ_LINGER\fR option shall retrieve the linger period for the specified \fIsocket\fR\&. The linger period determines how long pending messages which have yet to be sent to a peer shall linger in memory after a socket is closed with \fBzmq_close\fR(3), and further affects the termination of the socket\(cqs context with \fBzmq_term\fR(3)\&. The following outlines the different behaviours: +.sp +.RS 4 +.ie n \{\ +\h'-04'\(bu\h'+03'\c +.\} +.el \{\ +.sp -1 +.IP \(bu 2.3 +.\} +The default value of +\fI\-1\fR +specifies an infinite linger period\&. Pending messages shall not be discarded after a call to +\fIzmq_close()\fR; attempting to terminate the socket\(cqs context with +\fIzmq_term()\fR +shall block until all pending messages have been sent to a peer\&. +.RE +.sp +.RS 4 +.ie n \{\ +\h'-04'\(bu\h'+03'\c +.\} +.el \{\ +.sp -1 +.IP \(bu 2.3 +.\} +The value of +\fI0\fR +specifies no linger period\&. Pending messages shall be discarded immediately when the socket is closed with +\fIzmq_close()\fR\&. +.RE +.sp +.RS 4 +.ie n \{\ +\h'-04'\(bu\h'+03'\c +.\} +.el \{\ +.sp -1 +.IP \(bu 2.3 +.\} +Positive values specify an upper bound for the linger period in milliseconds\&. Pending messages shall not be discarded after a call to +\fIzmq_close()\fR; attempting to terminate the socket\(cqs context with +\fIzmq_term()\fR +shall block until either all pending messages have been sent to a peer, or the linger period expires, after which any pending messages shall be discarded\&. +.TS +tab(:); +lt lt +lt lt +lt lt +lt lt. +T{ +Option value type +T}:T{ +int +T} +T{ +Option value unit +T}:T{ +milliseconds +T} +T{ +Default value +T}:T{ +\-1 (infinite) +T} +T{ +Applicable socket types +T}:T{ +all +T} +.TE +.sp 1 +.RE +.SS "ZMQ_RECONNECT_IVL: Retrieve reconnection interval" +.sp +The \fIZMQ_RECONNECT_IVL\fR option shall retrieve the initial reconnection interval for the specified \fIsocket\fR\&. The reconnection interval is the period 0MQ shall wait between attempts to reconnect disconnected peers when using connection\-oriented transports\&. +.if n \{\ +.sp +.\} +.RS 4 +.it 1 an-trap +.nr an-no-space-flag 1 +.nr an-break-flag 1 +.br +.ps +1 +\fBNote\fR +.ps -1 +.br +.sp +The reconnection interval may be randomized by 0MQ to prevent reconnection storms in topologies with a large number of peers per socket\&. +.sp .5v +.RE +.TS +tab(:); +lt lt +lt lt +lt lt +lt lt. +T{ +.sp +Option value type +T}:T{ +.sp +int +T} +T{ +.sp +Option value unit +T}:T{ +.sp +milliseconds +T} +T{ +.sp +Default value +T}:T{ +.sp +100 +T} +T{ +.sp +Applicable socket types +T}:T{ +.sp +all, only for connection\-oriented transports +T} +.TE +.sp 1 +.SS "ZMQ_RECONNECT_IVL_MAX: Retrieve maximum reconnection interval" +.sp +The \fIZMQ_RECONNECT_IVL_MAX\fR option shall retrieve the maximum reconnection interval for the specified \fIsocket\fR\&. This is the maximum period 0MQ shall wait between attempts to reconnect\&. On each reconnect attempt, the previous interval shall be doubled untill ZMQ_RECONNECT_IVL_MAX is reached\&. This allows for exponential backoff strategy\&. Default value means no exponential backoff is performed and reconnect interval calculations are only based on ZMQ_RECONNECT_IVL\&. +.if n \{\ +.sp +.\} +.RS 4 +.it 1 an-trap +.nr an-no-space-flag 1 +.nr an-break-flag 1 +.br +.ps +1 +\fBNote\fR +.ps -1 +.br +.sp +Values less than ZMQ_RECONNECT_IVL will be ignored\&. +.sp .5v +.RE +.TS +tab(:); +lt lt +lt lt +lt lt +lt lt. +T{ +.sp +Option value type +T}:T{ +.sp +int +T} +T{ +.sp +Option value unit +T}:T{ +.sp +milliseconds +T} +T{ +.sp +Default value +T}:T{ +.sp +0 (only use ZMQ_RECONNECT_IVL) +T} +T{ +.sp +Applicable socket types +T}:T{ +.sp +all, only for connection\-oriented transport +T} +.TE +.sp 1 +.SS "ZMQ_BACKLOG: Retrieve maximum length of the queue of outstanding connections" +.sp +The \fIZMQ_BACKLOG\fR option shall retrieve the maximum length of the queue of outstanding peer connections for the specified \fIsocket\fR; this only applies to connection\-oriented transports\&. For details refer to your operating system documentation for the \fIlisten\fR function\&. +.TS +tab(:); +lt lt +lt lt +lt lt +lt lt. +T{ +.sp +Option value type +T}:T{ +.sp +int +T} +T{ +.sp +Option value unit +T}:T{ +.sp +connections +T} +T{ +.sp +Default value +T}:T{ +.sp +100 +T} +T{ +.sp +Applicable socket types +T}:T{ +.sp +all, only for connection\-oriented transports +T} +.TE +.sp 1 +.SS "ZMQ_FD: Retrieve file descriptor associated with the socket" +.sp +The \fIZMQ_FD\fR option shall retrieve the file descriptor associated with the specified \fIsocket\fR\&. The returned file descriptor can be used to integrate the socket into an existing event loop; the 0MQ library shall signal any pending events on the socket in an \fIedge\-triggered\fR fashion by making the file descriptor become ready for reading\&. +.if n \{\ +.sp +.\} +.RS 4 +.it 1 an-trap +.nr an-no-space-flag 1 +.nr an-break-flag 1 +.br +.ps +1 +\fBNote\fR +.ps -1 +.br +.sp +The ability to read from the returned file descriptor does not necessarily indicate that messages are available to be read from, or can be written to, the underlying socket; applications must retrieve the actual event state with a subsequent retrieval of the \fIZMQ_EVENTS\fR option\&. +.sp .5v +.RE +.if n \{\ +.sp +.\} +.RS 4 +.it 1 an-trap +.nr an-no-space-flag 1 +.nr an-break-flag 1 +.br +.ps +1 +\fBCaution\fR +.ps -1 +.br +.sp +The returned file descriptor is intended for use with a \fIpoll\fR or similar system call only\&. Applications must never attempt to read or write data to it directly, neither should they try to close it\&. +.sp .5v +.RE +.TS +tab(:); +lt lt +lt lt +lt lt +lt lt. +T{ +.sp +Option value type +T}:T{ +.sp +int on POSIX systems, SOCKET on Windows +T} +T{ +.sp +Option value unit +T}:T{ +.sp +N/A +T} +T{ +.sp +Default value +T}:T{ +.sp +N/A +T} +T{ +.sp +Applicable socket types +T}:T{ +.sp +all +T} +.TE +.sp 1 +.SS "ZMQ_EVENTS: Retrieve socket event state" +.sp +The \fIZMQ_EVENTS\fR option shall retrieve the event state for the specified \fIsocket\fR\&. The returned value is a bit mask constructed by OR\(cqing a combination of the following event flags: +.PP +\fBZMQ_POLLIN\fR +.RS 4 +Indicates that at least one message may be received from the specified socket without blocking\&. +.RE +.PP +\fBZMQ_POLLOUT\fR +.RS 4 +Indicates that at least one message may be sent to the specified socket without blocking\&. +.RE +.sp +The combination of a file descriptor returned by the \fIZMQ_FD\fR option being ready for reading but no actual events returned by a subsequent retrieval of the \fIZMQ_EVENTS\fR option is valid; applications should simply ignore this case and restart their polling operation/event loop\&. +.TS +tab(:); +lt lt +lt lt +lt lt +lt lt. +T{ +.sp +Option value type +T}:T{ +.sp +uint32_t +T} +T{ +.sp +Option value unit +T}:T{ +.sp +N/A (flags) +T} +T{ +.sp +Default value +T}:T{ +.sp +N/A +T} +T{ +.sp +Applicable socket types +T}:T{ +.sp +all +T} +.TE +.sp 1 .SH "RETURN VALUE" .sp The \fIzmq_getsockopt()\fR function shall return zero if successful\&. Otherwise it shall return \-1 and set \fIerrno\fR to one of the values defined below\&. @@ -476,6 +902,11 @@ The provided \fIsocket\fR was not valid (NULL)\&. .RE +.PP +\fBEINTR\fR +.RS 4 +The operation was interrupted by delivery of a signal\&. +.RE .SH "EXAMPLE" .PP \fBRetrieving the high water mark\fR. @@ -499,7 +930,7 @@ assert (rc == 0); \fBzmq_setsockopt\fR(3) \fBzmq_socket\fR(3) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_getsockopt.html b/doc/zmq_getsockopt.html deleted file mode 100644 index 972dbde..0000000 --- a/doc/zmq_getsockopt.html +++ /dev/null @@ -1,1202 +0,0 @@ - - - - - -zmq_getsockopt(3) - - - - - -
-

SYNOPSIS

-
-

int zmq_getsockopt (void *socket, int option_name, void *option_value, size_t *option_len);

-
-

DESCRIPTION

-
-

The zmq_getsockopt() function shall retrieve the value for the option -specified by the option_name argument for the ØMQ socket pointed to by the -socket argument, and store it in the buffer pointed to by the option_value -argument. The option_len argument is the size in bytes of the buffer pointed -to by option_value; upon successful completion zmq_getsockopt() shall -modify the option_len argument to indicate the actual size of the option -value stored in the buffer.

-

The following options can be retrieved with the zmq_getsockopt() function:

-

ZMQ_RCVMORE: More message parts to follow

-

The ZMQ_RCVMORE option shall return a boolean value indicating if the -multi-part message currently being read from the specified socket has more -message parts to follow. If there are no message parts to follow or if the -message currently being read is not a multi-part message a value of zero shall -be returned. Otherwise, a value of 1 shall be returned.

-

Refer to zmq_send(3) and zmq_recv(3) for a detailed description -of sending/receiving multi-part messages.

-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-int64_t -

-
-Option value unit -
-		 -

-boolean -

-
-Default value -
-		 -

-N/A -

-
-Applicable socket types -
-		 -

-all -

-
-

ZMQ_HWM: Retrieve high water mark

-

The ZMQ_HWM option shall retrieve the high water mark for the specified -socket. The high water mark is a hard limit on the maximum number of -outstanding messages ØMQ shall queue in memory for any single peer that the -specified socket is communicating with.

-

If this limit has been reached the socket shall enter an exceptional state and -depending on the socket type, ØMQ shall take appropriate action such as -blocking or dropping sent messages. Refer to the individual socket descriptions -in zmq_socket(3) for details on the exact action taken for each socket -type.

-

The default ZMQ_HWM value of zero means "no limit".

-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-uint64_t -

-
-Option value unit -
-		 -

-messages -

-
-Default value -
-		 -

-0 -

-
-Applicable socket types -
-		 -

-all -

-
-

ZMQ_SWAP: Retrieve disk offload size

-

The ZMQ_SWAP option shall retrieve the disk offload (swap) size for the -specified socket. A socket which has ZMQ_SWAP set to a non-zero value may -exceed it’s high water mark; in this case outstanding messages shall be -offloaded to storage on disk rather than held in memory.

-

The value of ZMQ_SWAP defines the maximum size of the swap space in bytes.

-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-int64_t -

-
-Option value unit -
-		 -

-bytes -

-
-Default value -
-		 -

-0 -

-
-Applicable socket types -
-		 -

-all -

-
-

ZMQ_AFFINITY: Retrieve I/O thread affinity

-

The ZMQ_AFFINITY option shall retrieve the I/O thread affinity for newly -created connections on the specified socket.

-

Affinity determines which threads from the ØMQ I/O thread pool associated with -the socket’s context shall handle newly created connections. A value of zero -specifies no affinity, meaning that work shall be distributed fairly among all -ØMQ I/O threads in the thread pool. For non-zero values, the lowest bit -corresponds to thread 1, second lowest bit to thread 2 and so on. For example, -a value of 3 specifies that subsequent connections on socket shall be handled -exclusively by I/O threads 1 and 2.

-

See also zmq_init(3) for details on allocating the number of I/O -threads for a specific context.

-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-uint64_t -

-
-Option value unit -
-		 -

-N/A (bitmap) -

-
-Default value -
-		 -

-0 -

-
-Applicable socket types -
-		 -

-N/A -

-
-

ZMQ_IDENTITY: Retrieve socket identity

-

The ZMQ_IDENTITY option shall retrieve the identity of the specified -socket. Socket identity determines if existing ØMQ infastructure (message -queues, forwarding devices) shall be identified with a specific application -and persist across multiple runs of the application.

-

If the socket has no identity, each run of an application is completely -separate from other runs. However, with identity set the socket shall re-use -any existing ØMQ infrastructure configured by the previous run(s). Thus the -application may receive messages that were sent in the meantime, message -queue limits shall be shared with previous run(s) and so on.

-

Identity can be at least one byte and at most 255 bytes long. Identities -starting with binary zero are reserved for use by ØMQ infrastructure.

-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-binary data -

-
-Option value unit -
-		 -

-N/A -

-
-Default value -
-		 -

-NULL -

-
-Applicable socket types -
-		 -

-all -

-
-

ZMQ_RATE: Retrieve multicast data rate

-

The ZMQ_RATE option shall retrieve the maximum send or receive data rate for -multicast transports using the specified socket.

-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-int64_t -

-
-Option value unit -
-		 -

-kilobits per second -

-
-Default value -
-		 -

-100 -

-
-Applicable socket types -
-		 -

-all, when using multicast transports -

-
-

ZMQ_RECOVERY_IVL: Get multicast recovery interval

-

The ZMQ_RECOVERY_IVL option shall retrieve the recovery interval for -multicast transports using the specified socket. The recovery interval -determines the maximum time in seconds that a receiver can be absent from a -multicast group before unrecoverable data loss will occur.

-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-int64_t -

-
-Option value unit -
-		 -

-seconds -

-
-Default value -
-		 -

-10 -

-
-Applicable socket types -
-		 -

-all, when using multicast transports -

-
-

ZMQ_MCAST_LOOP: Control multicast loopback

-

The ZMQ_MCAST_LOOP option controls whether data sent via multicast -transports can also be received by the sending host via loopback. A value of -zero indicates that the loopback functionality is disabled, while the default -value of 1 indicates that the loopback functionality is enabled. Leaving -multicast loopback enabled when it is not required can have a negative impact -on performance. Where possible, disable ZMQ_MCAST_LOOP in production -environments.

-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-int64_t -

-
-Option value unit -
-		 -

-boolean -

-
-Default value -
-		 -

-1 -

-
-Applicable socket types -
-		 -

-all, when using multicast transports -

-
-

ZMQ_SNDBUF: Retrieve kernel transmit buffer size

-

The ZMQ_SNDBUF option shall retrieve the underlying kernel transmit buffer -size for the specified socket. A value of zero means that the OS default is -in effect. For details refer to your operating system documentation for the -SO_SNDBUF socket option.

-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-uint64_t -

-
-Option value unit -
-		 -

-bytes -

-
-Default value -
-		 -

-0 -

-
-Applicable socket types -
-		 -

-all -

-
-

ZMQ_RCVBUF: Retrieve kernel receive buffer size

-

The ZMQ_RCVBUF option shall retrieve the underlying kernel receive buffer -size for the specified socket. A value of zero means that the OS default is -in effect. For details refer to your operating system documentation for the -SO_RCVBUF socket option.

-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-uint64_t -

-
-Option value unit -
-		 -

-bytes -

-
-Default value -
-		 -

-0 -

-
-Applicable socket types -
-		 -

-all -

-
-
-

RETURN VALUE

-
-

The zmq_getsockopt() function shall return zero if successful. Otherwise it -shall return -1 and set errno to one of the values defined below.

-
-

ERRORS

-
-
-
-EINVAL -
-
-

-The requested option option_name is unknown, or the requested option_len or -option_value is invalid, or the size of the buffer pointed to by -option_value, as specified by option_len, is insufficient for storing the -option value. -

-
-
-ETERM -
-
-

-The ØMQ context associated with the specified socket was terminated. -

-
-
-EFAULT -
-
-

-The provided socket was not valid (NULL). -

-
-
-
-

EXAMPLE

-
-
-
Retrieving the high water mark
-
-
/* Retrieve high water mark into hwm */
-int64_t hwm;
-size_t hwm_size = sizeof (hwm);
-rc = zmq_getsockopt (socket, ZMQ_HWM, &hwm, &hwm_size);
-assert (rc == 0);
-
-
-

SEE ALSO

-
-

zmq_setsockopt(3) -zmq_socket(3) -zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_getsockopt.txt b/doc/zmq_getsockopt.txt index 1e36a2a..1279fbc 100644 --- a/doc/zmq_getsockopt.txt +++ b/doc/zmq_getsockopt.txt @@ -26,6 +26,19 @@ value stored in the buffer. The following options can be retrieved with the _zmq_getsockopt()_ function: +ZMQ_TYPE: Retrieve socket type +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The 'ZMQ_TYPE' option shall retrieve the socket type for the specified +'socket'. The socket type is specified at socket creation time and +cannot be modified afterwards. + +[horizontal] +Option value type:: int +Option value unit:: N/A +Default value:: N/A +Applicable socket types:: all + + ZMQ_RCVMORE: More message parts to follow ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The 'ZMQ_RCVMORE' option shall return a boolean value indicating if the @@ -108,7 +121,7 @@ Applicable socket types:: N/A ZMQ_IDENTITY: Retrieve socket identity ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The 'ZMQ_IDENTITY' option shall retrieve the identity of the specified -'socket'. Socket identity determines if existing 0MQ infastructure (_message +'socket'. Socket identity determines if existing 0MQ infrastructure (_message queues_, _forwarding devices_) shall be identified with a specific application and persist across multiple runs of the application. @@ -154,13 +167,33 @@ Default value:: 10 Applicable socket types:: all, when using multicast transports -ZMQ_MCAST_LOOP: Control multicast loopback -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +ZMQ_RECOVERY_IVL_MSEC: Get multicast recovery interval in milliseconds +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The 'ZMQ_RECOVERY_IVL'_MSEC option shall retrieve the recovery interval, in +milliseconds, for multicast transports using the specified 'socket'. The +recovery interval determines the maximum time in seconds that a receiver +can be absent from a multicast group before unrecoverable data loss will +occur. + +For backward compatibility, the default value of 'ZMQ_RECOVERY_IVL_MSEC' is +-1 indicating that the recovery interval should be obtained from the +'ZMQ_RECOVERY_IVL' option. However, if the 'ZMQ_RECOVERY_IVL_MSEC' value is +not zero, then it will take precedence, and be used. + +[horizontal] +Option value type:: int64_t +Option value unit:: milliseconds +Default value:: -1 +Applicable socket types:: all, when using multicast transports + + +ZMQ_MCAST_LOOP: Control multicast loop-back +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The 'ZMQ_MCAST_LOOP' option controls whether data sent via multicast -transports can also be received by the sending host via loopback. A value of -zero indicates that the loopback functionality is disabled, while the default -value of 1 indicates that the loopback functionality is enabled. Leaving -multicast loopback enabled when it is not required can have a negative impact +transports can also be received by the sending host via loop-back. A value of +zero indicates that the loop-back functionality is disabled, while the default +value of 1 indicates that the loop-back functionality is enabled. Leaving +multicast loop-back enabled when it is not required can have a negative impact on performance. Where possible, disable 'ZMQ_MCAST_LOOP' in production environments. @@ -199,6 +232,135 @@ Default value:: 0 Applicable socket types:: all +ZMQ_LINGER: Retrieve linger period for socket shutdown +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The 'ZMQ_LINGER' option shall retrieve the linger period for the specified +'socket'. The linger period determines how long pending messages which have +yet to be sent to a peer shall linger in memory after a socket is closed with +linkzmq:zmq_close[3], and further affects the termination of the socket's +context with linkzmq:zmq_term[3]. The following outlines the different +behaviours: + +* The default value of '-1' specifies an infinite linger period. Pending + messages shall not be discarded after a call to _zmq_close()_; attempting to + terminate the socket's context with _zmq_term()_ shall block until all + pending messages have been sent to a peer. + +* The value of '0' specifies no linger period. Pending messages shall be + discarded immediately when the socket is closed with _zmq_close()_. + +* Positive values specify an upper bound for the linger period in milliseconds. + Pending messages shall not be discarded after a call to _zmq_close()_; + attempting to terminate the socket's context with _zmq_term()_ shall block + until either all pending messages have been sent to a peer, or the linger + period expires, after which any pending messages shall be discarded. + +[horizontal] +Option value type:: int +Option value unit:: milliseconds +Default value:: -1 (infinite) +Applicable socket types:: all + + +ZMQ_RECONNECT_IVL: Retrieve reconnection interval +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The 'ZMQ_RECONNECT_IVL' option shall retrieve the initial reconnection interval +for the specified 'socket'. The reconnection interval is the period 0MQ shall +wait between attempts to reconnect disconnected peers when using +connection-oriented transports. + +NOTE: The reconnection interval may be randomized by 0MQ to prevent +reconnection storms in topologies with a large number of peers per socket. + +[horizontal] +Option value type:: int +Option value unit:: milliseconds +Default value:: 100 +Applicable socket types:: all, only for connection-oriented transports + + +ZMQ_RECONNECT_IVL_MAX: Retrieve maximum reconnection interval +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The 'ZMQ_RECONNECT_IVL_MAX' option shall retrieve the maximum reconnection +interval for the specified 'socket'. This is the maximum period 0MQ shall wait +between attempts to reconnect. On each reconnect attempt, the previous interval +shall be doubled untill ZMQ_RECONNECT_IVL_MAX is reached. This allows for +exponential backoff strategy. Default value means no exponential backoff is +performed and reconnect interval calculations are only based on ZMQ_RECONNECT_IVL. + +NOTE: Values less than ZMQ_RECONNECT_IVL will be ignored. + +[horizontal] +Option value type:: int +Option value unit:: milliseconds +Default value:: 0 (only use ZMQ_RECONNECT_IVL) +Applicable socket types:: all, only for connection-oriented transport + + +ZMQ_BACKLOG: Retrieve maximum length of the queue of outstanding connections +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The 'ZMQ_BACKLOG' option shall retrieve the maximum length of the queue of +outstanding peer connections for the specified 'socket'; this only applies to +connection-oriented transports. For details refer to your operating system +documentation for the 'listen' function. + +[horizontal] +Option value type:: int +Option value unit:: connections +Default value:: 100 +Applicable socket types:: all, only for connection-oriented transports + + +ZMQ_FD: Retrieve file descriptor associated with the socket +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The 'ZMQ_FD' option shall retrieve the file descriptor associated with the +specified 'socket'. The returned file descriptor can be used to integrate the +socket into an existing event loop; the 0MQ library shall signal any pending +events on the socket in an _edge-triggered_ fashion by making the file +descriptor become ready for reading. + +NOTE: The ability to read from the returned file descriptor does not +necessarily indicate that messages are available to be read from, or can be +written to, the underlying socket; applications must retrieve the actual event +state with a subsequent retrieval of the 'ZMQ_EVENTS' option. + +CAUTION: The returned file descriptor is intended for use with a 'poll' or +similar system call only. Applications must never attempt to read or write data +to it directly, neither should they try to close it. + +[horizontal] +Option value type:: int on POSIX systems, SOCKET on Windows +Option value unit:: N/A +Default value:: N/A +Applicable socket types:: all + + +ZMQ_EVENTS: Retrieve socket event state +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The 'ZMQ_EVENTS' option shall retrieve the event state for the specified +'socket'. The returned value is a bit mask constructed by OR'ing a combination +of the following event flags: + +*ZMQ_POLLIN*:: +Indicates that at least one message may be received from the specified socket +without blocking. + +*ZMQ_POLLOUT*:: +Indicates that at least one message may be sent to the specified socket without +blocking. + +The combination of a file descriptor returned by the 'ZMQ_FD' option being +ready for reading but no actual events returned by a subsequent retrieval of +the 'ZMQ_EVENTS' option is valid; applications should simply ignore this case +and restart their polling operation/event loop. + +[horizontal] +Option value type:: uint32_t +Option value unit:: N/A (flags) +Default value:: N/A +Applicable socket types:: all + + RETURN VALUE ------------ The _zmq_getsockopt()_ function shall return zero if successful. Otherwise it @@ -216,6 +378,8 @@ option value. The 0MQ 'context' associated with the specified 'socket' was terminated. *EFAULT*:: The provided 'socket' was not valid (NULL). +*EINTR*:: +The operation was interrupted by delivery of a signal. EXAMPLE @@ -239,5 +403,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_init.3 b/doc/zmq_init.3 index ea52ea3..12fbe75 100644 --- a/doc/zmq_init.3 +++ b/doc/zmq_init.3 @@ -2,12 +2,12 @@ .\" Title: zmq_init .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_INIT" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_INIT" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -37,6 +37,10 @@ zmq_init \- initialise 0MQ context The \fIzmq_init()\fR function initialises a 0MQ \fIcontext\fR\&. .sp The \fIio_threads\fR argument specifies the size of the 0MQ thread pool to handle I/O operations\&. If your application is using only the \fIinproc\fR transport for messaging you may set this to zero, otherwise set it to at least one\&. +.PP +\fBThread safety\fR. A 0MQ +\fIcontext\fR +is thread safe and may be shared among as many application threads as necessary, without any additional locking required on the part of the caller\&. .SH "RETURN VALUE" .sp The \fIzmq_init()\fR function shall return an opaque handle to the initialised \fIcontext\fR if successful\&. Otherwise it shall return NULL and set \fIerrno\fR to one of the values defined below\&. @@ -53,7 +57,7 @@ was requested\&. \fBzmq\fR(7) \fBzmq_term\fR(3) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_init.html b/doc/zmq_init.html deleted file mode 100644 index 3248e3f..0000000 --- a/doc/zmq_init.html +++ /dev/null @@ -1,632 +0,0 @@ - - - - - -zmq_init(3) - - - - - -
-

SYNOPSIS

-
-

void *zmq_init (int io_threads);

-
-

DESCRIPTION

-
-

The zmq_init() function initialises a ØMQ context.

-

The io_threads argument specifies the size of the ØMQ thread pool to handle -I/O operations. If your application is using only the inproc transport for -messaging you may set this to zero, otherwise set it to at least one.

-
-

RETURN VALUE

-
-

The zmq_init() function shall return an opaque handle to the initialised -context if successful. Otherwise it shall return NULL and set errno to one -of the values defined below.

-
-

ERRORS

-
-
-
-EINVAL -
-
-

-An invalid number of io_threads was requested. -

-
-
-
-

SEE ALSO

-
-

zmq(7) -zmq_term(3)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_init.txt b/doc/zmq_init.txt index 04bbbc8..eadf65d 100644 --- a/doc/zmq_init.txt +++ b/doc/zmq_init.txt @@ -20,6 +20,11 @@ The 'io_threads' argument specifies the size of the 0MQ thread pool to handle I/O operations. If your application is using only the 'inproc' transport for messaging you may set this to zero, otherwise set it to at least one. +.Thread safety +A 0MQ 'context' is thread safe and may be shared among as many application +threads as necessary, without any additional locking required on the part of +the caller. + RETURN VALUE ------------ @@ -42,5 +47,5 @@ linkzmq:zmq_term[3] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_inproc.7 b/doc/zmq_inproc.7 index e9cb0f1..a6839e3 100644 --- a/doc/zmq_inproc.7 +++ b/doc/zmq_inproc.7 @@ -2,12 +2,12 @@ .\" Title: zmq_inproc .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_INPROC" "7" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_INPROC" "7" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -101,7 +101,7 @@ assert (rc == 0); \fBzmq_bind\fR(3) \fBzmq_connect\fR(3) \fBzmq_ipc\fR(7) \fBzmq_tcp\fR(7) \fBzmq_pgm\fR(7) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_inproc.html b/doc/zmq_inproc.html deleted file mode 100644 index 8a3aceb..0000000 --- a/doc/zmq_inproc.html +++ /dev/null @@ -1,669 +0,0 @@ - - - - - -zmq_inproc(7) - - - - - -
-

SYNOPSIS

-
-

The in-process transport passes messages via memory directly between threads -sharing a single ØMQ context.

-
- - - -
-
Note
-		No I/O threads are involved in passing messages using the inproc -transport. Therefore, if you are using a ØMQ context for in-process messaging -only you can initialise the context with zero I/O threads. See -zmq_init(3) for details.
-
-
-

ADDRESSING

-
-

A ØMQ address string consists of two parts as follows: -transport://endpoint. The transport part specifies the underlying -transport protocol to use, and for the in-process transport shall be set to -inproc. The meaning of the endpoint part for the in-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 -inproc transport, the endpoint shall be interpreted as an arbitrary string -identifying the name to create. The name must be unique within the ØMQ -context associated with the socket and may be up to 256 characters in -length. No other restrictions are placed on the format of the name.

-

Connecting a socket

-

When connecting a socket to a peer address using zmq_connect() with the -inproc transport, the endpoint shall be interpreted as an arbitrary string -identifying the name to connect to. The name must have been previously -created by assigning it to at least one socket within the same ØMQ context -as the socket being connected.

-
-

WIRE FORMAT

-
-

Not applicable.

-
-

EXAMPLES

-
-
-
Assigning a local address to a socket
-
-
/* Assign the in-process name "#1" */
-rc = zmq_bind(socket, "inproc://#1");
-assert (rc == 0);
-/* Assign the in-process name "my-endpoint" */
-rc = zmq_bind(socket, "inproc://my-endpoint");
-assert (rc == 0);
-
-
-
Connecting a socket
-
-
/* Connect to the in-process name "#1" */
-rc = zmq_connect(socket, "inproc://#1");
-assert (rc == 0);
-/* Connect to the in-process name "my-endpoint" */
-rc = zmq_connect(socket, "inproc://my-endpoint");
-assert (rc == 0);
-
-
-

SEE ALSO

-
-

zmq_bind(3) -zmq_connect(3) -zmq_ipc(7) -zmq_tcp(7) -zmq_pgm(7) -zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_inproc.txt b/doc/zmq_inproc.txt index 2805f71..e68e14b 100644 --- a/doc/zmq_inproc.txt +++ b/doc/zmq_inproc.txt @@ -85,5 +85,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_ipc.7 b/doc/zmq_ipc.7 index 49d9e9e..0d20a4a 100644 --- a/doc/zmq_ipc.7 +++ b/doc/zmq_ipc.7 @@ -2,12 +2,12 @@ .\" Title: zmq_ipc .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_IPC" "7" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_IPC" "7" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -95,7 +95,7 @@ assert (rc == 0); \fBzmq_bind\fR(3) \fBzmq_connect\fR(3) \fBzmq_inproc\fR(7) \fBzmq_tcp\fR(7) \fBzmq_pgm\fR(7) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_ipc.html b/doc/zmq_ipc.html deleted file mode 100644 index f300728..0000000 --- a/doc/zmq_ipc.html +++ /dev/null @@ -1,662 +0,0 @@ - - - - - -zmq_ipc(7) - - - - - -
-

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 ØMQ 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

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_ipc.txt b/doc/zmq_ipc.txt index 81f6747..974ad24 100644 --- a/doc/zmq_ipc.txt +++ b/doc/zmq_ipc.txt @@ -76,5 +76,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_msg_close.3 b/doc/zmq_msg_close.3 index 0361d6a..1e7cdae 100644 --- a/doc/zmq_msg_close.3 +++ b/doc/zmq_msg_close.3 @@ -2,12 +2,12 @@ .\" Title: zmq_msg_close .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_MSG_CLOSE" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_MSG_CLOSE" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -64,7 +64,7 @@ No errors are defined\&. \fBzmq_msg_init\fR(3) \fBzmq_msg_init_size\fR(3) \fBzmq_msg_init_data\fR(3) \fBzmq_msg_data\fR(3) \fBzmq_msg_size\fR(3) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_msg_close.html b/doc/zmq_msg_close.html deleted file mode 100644 index bc01ec2..0000000 --- a/doc/zmq_msg_close.html +++ /dev/null @@ -1,638 +0,0 @@ - - - - - -zmq_msg_close(3) - - - - - -
-

SYNOPSIS

-
-

int zmq_msg_close (zmq_msg_t *msg);

-
-

DESCRIPTION

-
-

The zmq_msg_close() function shall inform the ØMQ infrastructure that any -resources associated with the message object referenced by msg are no longer -required and may be released. Actual release of resources associated with the -message object shall be postponed by ØMQ until all users of the message or -underlying data buffer have indicated it is no longer required.

-

Applications should ensure that zmq_msg_close() is called once a message is -no longer required, otherwise memory leaks may occur.

-
- - - -
-
Caution
-		Never access zmq_msg_t members directly, instead always use the -zmq_msg family of functions.
-
-
-

RETURN VALUE

-
-

The zmq_msg_close() function shall return zero if successful. Otherwise -it shall return -1 and set errno to one of the values defined below.

-
-

ERRORS

-
-

No errors are defined.

-
-

SEE ALSO

-
-

zmq_msg_init(3) -zmq_msg_init_size(3) -zmq_msg_init_data(3) -zmq_msg_data(3) -zmq_msg_size(3) -zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_msg_close.txt b/doc/zmq_msg_close.txt index 1da353b..f72251a 100644 --- a/doc/zmq_msg_close.txt +++ b/doc/zmq_msg_close.txt @@ -50,5 +50,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_msg_copy.3 b/doc/zmq_msg_copy.3 index aa2d5d7..9fc0f7e 100644 --- a/doc/zmq_msg_copy.3 +++ b/doc/zmq_msg_copy.3 @@ -2,12 +2,12 @@ .\" Title: zmq_msg_copy .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_MSG_COPY" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_MSG_COPY" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -78,7 +78,7 @@ No errors are defined\&. \fBzmq_msg_move\fR(3) \fBzmq_msg_init\fR(3) \fBzmq_msg_init_size\fR(3) \fBzmq_msg_init_data\fR(3) \fBzmq_msg_close\fR(3) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_msg_copy.html b/doc/zmq_msg_copy.html deleted file mode 100644 index 085c449..0000000 --- a/doc/zmq_msg_copy.html +++ /dev/null @@ -1,647 +0,0 @@ - - - - - -zmq_msg_copy(3) - - - - - -
-

SYNOPSIS

-
-

int zmq_msg_copy (zmq_msg_t *dest, zmq_msg_t *src);

-
-

DESCRIPTION

-
-

The zmq_msg_copy() function shall copy the message object referenced by src -to the message object referenced by dest. The original content of dest, if -any, shall be released.

-
- - - -
-
Caution
-		The implementation may choose not to physically copy the message -content, rather to share the underlying buffer between src and dest. Avoid -modifying message content after a message has been copied with -zmq_msg_copy(), doing so can result in undefined behaviour. If what you need -is an actual hard copy, allocate a new message using zmq_msg_init_size() and -copy the message content using memcpy().
-
-
- - - -
-
Caution
-		Never access zmq_msg_t members directly, instead always use the -zmq_msg family of functions.
-
-
-

RETURN VALUE

-
-

The zmq_msg_copy() function shall return zero if successful. Otherwise it -shall return -1 and set errno to one of the values defined below.

-
-

ERRORS

-
-

No errors are defined.

-
-

SEE ALSO

-
-

zmq_msg_move(3) -zmq_msg_init(3) -zmq_msg_init_size(3) -zmq_msg_init_data(3) -zmq_msg_close(3) -zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_msg_copy.txt b/doc/zmq_msg_copy.txt index f41a42e..d23dcdb 100644 --- a/doc/zmq_msg_copy.txt +++ b/doc/zmq_msg_copy.txt @@ -52,5 +52,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_msg_data.3 b/doc/zmq_msg_data.3 index b966299..a2d31a4 100644 --- a/doc/zmq_msg_data.3 +++ b/doc/zmq_msg_data.3 @@ -2,12 +2,12 @@ .\" Title: zmq_msg_data .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_MSG_DATA" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_MSG_DATA" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -62,7 +62,7 @@ No errors are defined\&. \fBzmq_msg_size\fR(3) \fBzmq_msg_init\fR(3) \fBzmq_msg_init_size\fR(3) \fBzmq_msg_init_data\fR(3) \fBzmq_msg_close\fR(3) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_msg_data.html b/doc/zmq_msg_data.html deleted file mode 100644 index 9444a5f..0000000 --- a/doc/zmq_msg_data.html +++ /dev/null @@ -1,633 +0,0 @@ - - - - - -zmq_msg_data(3) - - - - - -
-

SYNOPSIS

-
-

void *zmq_msg_data (zmq_msg_t *msg);

-
-

DESCRIPTION

-
-

The zmq_msg_data() function shall return a pointer to the message content of -the message object referenced by msg.

-
- - - -
-
Caution
-		Never access zmq_msg_t members directly, instead always use the -zmq_msg family of functions.
-
-
-

RETURN VALUE

-
-

Upon successful completion, zmq_msg_data() shall return a pointer to the -message content.

-
-

ERRORS

-
-

No errors are defined.

-
-

SEE ALSO

-
-

zmq_msg_size(3) -zmq_msg_init(3) -zmq_msg_init_size(3) -zmq_msg_init_data(3) -zmq_msg_close(3) -zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_msg_data.txt b/doc/zmq_msg_data.txt index dbf6612..36a3ce3 100644 --- a/doc/zmq_msg_data.txt +++ b/doc/zmq_msg_data.txt @@ -44,5 +44,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_msg_init.3 b/doc/zmq_msg_init.3 index bbbd50f..dc080dd 100644 --- a/doc/zmq_msg_init.3 +++ b/doc/zmq_msg_init.3 @@ -2,12 +2,12 @@ .\" Title: zmq_msg_init .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_MSG_INIT" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_MSG_INIT" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -96,7 +96,7 @@ assert (rc == 0); \fBzmq_msg_init_size\fR(3) \fBzmq_msg_init_data\fR(3) \fBzmq_msg_close\fR(3) \fBzmq_msg_data\fR(3) \fBzmq_msg_size\fR(3) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_msg_init.html b/doc/zmq_msg_init.html deleted file mode 100644 index 4964c66..0000000 --- a/doc/zmq_msg_init.html +++ /dev/null @@ -1,656 +0,0 @@ - - - - - -zmq_msg_init(3) - - - - - -
-

SYNOPSIS

-
-

int zmq_msg_init (zmq_msg_t *msg);

-
-

DESCRIPTION

-
-

The zmq_msg_init() function shall initialise the message object referenced by -msg to represent an empty message. This function is most useful when called -before receiving a message with zmq_recv().

-
- - - -
-
Caution
-		Never access zmq_msg_t members directly, instead always use the -zmq_msg family of functions.
-
-
- - - -
-
Caution
-		The functions zmq_msg_init(), zmq_msg_init_data() and -zmq_msg_init_size() are mutually exclusive. Never initialize the same -zmq_msg_t twice.
-
-
-

RETURN VALUE

-
-

The zmq_msg_init() function shall return zero if successful. Otherwise it -shall return -1 and set errno to one of the values defined below.

-
-

ERRORS

-
-

No errors are defined.

-
-

EXAMPLE

-
-
-
Receiving a message from a socket
-
-
zmq_msg_t msg;
-rc = zmq_msg_init (&msg);
-assert (rc == 0);
-rc = zmq_recv (socket, &msg, 0);
-assert (rc == 0);
-
-
-

SEE ALSO

-
-

zmq_msg_init_size(3) -zmq_msg_init_data(3) -zmq_msg_close(3) -zmq_msg_data(3) -zmq_msg_size(3) -zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_msg_init.txt b/doc/zmq_msg_init.txt index d31dbae..1c2577d 100644 --- a/doc/zmq_msg_init.txt +++ b/doc/zmq_msg_init.txt @@ -61,5 +61,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_msg_init_data.3 b/doc/zmq_msg_init_data.3 index 928f84e..11f822d 100644 --- a/doc/zmq_msg_init_data.3 +++ b/doc/zmq_msg_init_data.3 @@ -2,12 +2,12 @@ .\" Title: zmq_msg_init_data .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_MSG_INIT_DATA" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_MSG_INIT_DATA" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -108,7 +108,7 @@ assert (rc == 0); \fBzmq_msg_init_size\fR(3) \fBzmq_msg_init\fR(3) \fBzmq_msg_close\fR(3) \fBzmq_msg_data\fR(3) \fBzmq_msg_size\fR(3) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_msg_init_data.html b/doc/zmq_msg_init_data.html deleted file mode 100644 index 2d93dee..0000000 --- a/doc/zmq_msg_init_data.html +++ /dev/null @@ -1,669 +0,0 @@ - - - - - -zmq_msg_init_data(3) - - - - - -
-

SYNOPSIS

-
-

typedef void (zmq_free_fn) (void *data, void *hint);

-

int zmq_msg_init_data (zmq_msg_t *msg, void *data, size_t size, zmq_free_fn *ffn, void *hint);

-
-

DESCRIPTION

-
-

The zmq_msg_init_data() function shall initialise the message object -referenced by msg to represent the content referenced by the buffer located -at address data, size bytes long. No copy of data shall be performed and -ØMQ shall take ownership of the supplied buffer.

-

If provided, the deallocation function ffn shall be called once the data -buffer is no longer required by ØMQ, with the data and hint arguments -supplied to zmq_msg_init_data().

-
- - - -
-
Caution
-		Never access zmq_msg_t members directly, instead always use the -zmq_msg family of functions.
-
-
- - - -
-
Caution
-		The functions zmq_msg_init(), zmq_msg_init_data() and -zmq_msg_init_size() are mutually exclusive. Never initialize the same -zmq_msg_t twice.
-
-
-

RETURN VALUE

-
-

The zmq_msg_init_data() function shall return zero if successful. Otherwise -it shall return -1 and set errno to one of the values defined below.

-
-

ERRORS

-
-

No errors are defined.

-
-

EXAMPLE

-
-
-
Initialising a message from a supplied buffer
-
-
void my_free (void *data, void *hint)
-{
-    free (data);
-}
-
-    /*  ...  */
-
-void *data = malloc (6);
-assert (data);
-memcpy (data, "ABCDEF", 6);
-zmq_msg_t msg;
-rc = zmq_msg_init_data (&msg, data, 6, my_free, NULL);
-assert (rc == 0);
-
-
-

SEE ALSO

-
-

zmq_msg_init_size(3) -zmq_msg_init(3) -zmq_msg_close(3) -zmq_msg_data(3) -zmq_msg_size(3) -zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_msg_init_data.txt b/doc/zmq_msg_init_data.txt index 8378757..50f05c5 100644 --- a/doc/zmq_msg_init_data.txt +++ b/doc/zmq_msg_init_data.txt @@ -76,5 +76,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_msg_init_size.3 b/doc/zmq_msg_init_size.3 index 5290f90..2f7c494 100644 --- a/doc/zmq_msg_init_size.3 +++ b/doc/zmq_msg_init_size.3 @@ -2,12 +2,12 @@ .\" Title: zmq_msg_init_size .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_MSG_INIT_SIZE" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_MSG_INIT_SIZE" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -83,7 +83,7 @@ Insufficient storage space is available\&. \fBzmq_msg_init_data\fR(3) \fBzmq_msg_init\fR(3) \fBzmq_msg_close\fR(3) \fBzmq_msg_data\fR(3) \fBzmq_msg_size\fR(3) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_msg_init_size.html b/doc/zmq_msg_init_size.html deleted file mode 100644 index 64ac76c..0000000 --- a/doc/zmq_msg_init_size.html +++ /dev/null @@ -1,656 +0,0 @@ - - - - - -zmq_msg_init_size(3) - - - - - -
-

SYNOPSIS

-
-

int zmq_msg_init_size (zmq_msg_t *msg, size_t size);

-
-

DESCRIPTION

-
-

The zmq_msg_init_size() function shall allocate any resources required to -store a message size bytes long and initialise the message object referenced -by msg to represent the newly allocated message.

-

The implementation shall choose whether to store message content on the stack -(small messages) or on the heap (large messages). For performance reasons -zmq_msg_init_size() shall not clear the message data.

-
- - - -
-
Caution
-		Never access zmq_msg_t members directly, instead always use the -zmq_msg family of functions.
-
-
- - - -
-
Caution
-		The functions zmq_msg_init(), zmq_msg_init_data() and -zmq_msg_init_size() are mutually exclusive. Never initialize the same -zmq_msg_t twice.
-
-
-

RETURN VALUE

-
-

The zmq_msg_init_size() function shall return zero if successful. Otherwise -it shall return -1 and set errno to one of the values defined below.

-
-

ERRORS

-
-
-
-ENOMEM -
-
-

-Insufficient storage space is available. -

-
-
-
-

SEE ALSO

-
-

zmq_msg_init_data(3) -zmq_msg_init(3) -zmq_msg_close(3) -zmq_msg_data(3) -zmq_msg_size(3) -zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_msg_init_size.txt b/doc/zmq_msg_init_size.txt index b4ef393..9be6263 100644 --- a/doc/zmq_msg_init_size.txt +++ b/doc/zmq_msg_init_size.txt @@ -54,5 +54,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_msg_move.3 b/doc/zmq_msg_move.3 index 458bdd5..6a3f97c 100644 --- a/doc/zmq_msg_move.3 +++ b/doc/zmq_msg_move.3 @@ -2,12 +2,12 @@ .\" Title: zmq_msg_move .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_MSG_MOVE" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_MSG_MOVE" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -62,7 +62,7 @@ No errors are defined\&. \fBzmq_msg_copy\fR(3) \fBzmq_msg_init\fR(3) \fBzmq_msg_init_size\fR(3) \fBzmq_msg_init_data\fR(3) \fBzmq_msg_close\fR(3) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_msg_move.html b/doc/zmq_msg_move.html deleted file mode 100644 index 1c8e155..0000000 --- a/doc/zmq_msg_move.html +++ /dev/null @@ -1,636 +0,0 @@ - - - - - -zmq_msg_move(3) - - - - - -
-

SYNOPSIS

-
-

int zmq_msg_move (zmq_msg_t *dest, zmq_msg_t *src);

-
-

DESCRIPTION

-
-

The zmq_msg_move() function shall move the content of the message object -referenced by src to the message object referenced by dest. No actual -copying of message content is performed, dest is simply updated to reference -the new content. src becomes an empty message after calling zmq_msg_move(). -The original content of dest, if any, shall be released.

-
- - - -
-
Caution
-		Never access zmq_msg_t members directly, instead always use the -zmq_msg family of functions.
-
-
-

RETURN VALUE

-
-

The zmq_msg_move() function shall return zero if successful. Otherwise it -shall return -1 and set errno to one of the values defined below.

-
-

ERRORS

-
-

No errors are defined.

-
-

SEE ALSO

-
-

zmq_msg_copy(3) -zmq_msg_init(3) -zmq_msg_init_size(3) -zmq_msg_init_data(3) -zmq_msg_close(3) -zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_msg_move.txt b/doc/zmq_msg_move.txt index 75c8e74..5e4081b 100644 --- a/doc/zmq_msg_move.txt +++ b/doc/zmq_msg_move.txt @@ -47,5 +47,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_msg_size.3 b/doc/zmq_msg_size.3 index 0384e6b..627c084 100644 --- a/doc/zmq_msg_size.3 +++ b/doc/zmq_msg_size.3 @@ -2,12 +2,12 @@ .\" Title: zmq_msg_size .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_MSG_SIZE" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_MSG_SIZE" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -62,7 +62,7 @@ No errors are defined\&. \fBzmq_msg_data\fR(3) \fBzmq_msg_init\fR(3) \fBzmq_msg_init_size\fR(3) \fBzmq_msg_init_data\fR(3) \fBzmq_msg_close\fR(3) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_msg_size.html b/doc/zmq_msg_size.html deleted file mode 100644 index 176e8ad..0000000 --- a/doc/zmq_msg_size.html +++ /dev/null @@ -1,633 +0,0 @@ - - - - - -zmq_msg_size(3) - - - - - -
-

SYNOPSIS

-
-

size_t zmq_msg_size (zmq_msg_t *msg);

-
-

DESCRIPTION

-
-

The zmq_msg_size() function shall return the size in bytes of the content of -the message object referenced by msg.

-
- - - -
-
Caution
-		Never access zmq_msg_t members directly, instead always use the -zmq_msg family of functions.
-
-
-

RETURN VALUE

-
-

Upon successful completion, zmq_msg_data() shall return the size of the -message content in bytes.

-
-

ERRORS

-
-

No errors are defined.

-
-

SEE ALSO

-
-

zmq_msg_data(3) -zmq_msg_init(3) -zmq_msg_init_size(3) -zmq_msg_init_data(3) -zmq_msg_close(3) -zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_msg_size.txt b/doc/zmq_msg_size.txt index 05abfa6..dd11235 100644 --- a/doc/zmq_msg_size.txt +++ b/doc/zmq_msg_size.txt @@ -44,5 +44,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_pgm.7 b/doc/zmq_pgm.7 index 9135e1c..06cc456 100644 --- a/doc/zmq_pgm.7 +++ b/doc/zmq_pgm.7 @@ -2,12 +2,12 @@ .\" Title: zmq_pgm .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_PGM" "7" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_PGM" "7" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -38,7 +38,7 @@ PGM (Pragmatic General Multicast) is a protocol for reliable multicast transport .sp The \fIpgm\fR and \fIepgm\fR transports can only be used with the \fIZMQ_PUB\fR and \fIZMQ_SUB\fR socket types\&. .sp -Further, PGM sockets are rate limited by default and incur a performance penalty when used over a loopback interface\&. For details, refer to the \fIZMQ_RATE\fR, \fIZMQ_RECOVERY_IVL\fR and \fIZMQ_MCAST_LOOP\fR options documented in \fBzmq_setsockopt\fR(3)\&. +Further, PGM sockets are rate limited by default and incur a performance penalty when used over a loop\-back interface\&. For details, refer to the \fIZMQ_RATE\fR, \fIZMQ_RECOVERY_IVL\fR and \fIZMQ_MCAST_LOOP\fR options documented in \fBzmq_setsockopt\fR(3)\&. .if n \{\ .sp .\} @@ -105,7 +105,7 @@ Interface names are not standardised in any way and should be assumed to be arbi A \fImulticast address\fR is specified by an IPv4 multicast address in it\(cqs numeric representation\&. .SH "WIRE FORMAT" .sp -Consecutive PGM datagrams are interpreted by 0MQ as a single continous stream of data where 0MQ messages are not necessarily aligned with PGM datagram boundaries and a single 0MQ message may span several PGM datagrams\&. This stream of data consists of 0MQ messages encapsulated in \fIframes\fR as described in \fBzmq_tcp\fR(7)\&. +Consecutive PGM datagrams are interpreted by 0MQ as a single continuous stream of data where 0MQ messages are not necessarily aligned with PGM datagram boundaries and a single 0MQ message may span several PGM datagrams\&. This stream of data consists of 0MQ messages encapsulated in \fIframes\fR as described in \fBzmq_tcp\fR(7)\&. .SS "PGM datagram payload" .sp The following ABNF grammar represents the payload of a single PGM datagram as used by 0MQ: @@ -174,7 +174,7 @@ Third datagram payload .\} .nf /* Connecting to the multicast address 239\&.192\&.1\&.1, port 5555, */ -/* using the first ethernet network interface on Linux */ +/* using the first Ethernet network interface on Linux */ /* and the Encapsulated PGM protocol */ rc = zmq_connect(socket, "epgm://eth0;239\&.192\&.1\&.1:5555"); assert (rc == 0); @@ -193,7 +193,7 @@ assert (rc == 0); \fBzmq_connect\fR(3) \fBzmq_setsockopt\fR(3) \fBzmq_tcp\fR(7) \fBzmq_ipc\fR(7) \fBzmq_inproc\fR(7) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_pgm.html b/doc/zmq_pgm.html deleted file mode 100644 index 06a1b70..0000000 --- a/doc/zmq_pgm.html +++ /dev/null @@ -1,745 +0,0 @@ - - - - - -zmq_pgm(7) - - - - - -
-

SYNOPSIS

-
-

PGM (Pragmatic General Multicast) is a protocol for reliable multicast -transport of data over IP networks.

-
-

DESCRIPTION

-
-

ØMQ implements two variants of PGM, the standard protocol where PGM datagrams -are layered directly on top of IP datagrams as defined by RFC 3208 (the pgm -transport) and "Encapsulated PGM" where PGM datagrams are encapsulated inside -UDP datagrams (the epgm transport).

-

The pgm and epgm transports can only be used with the ZMQ_PUB and -ZMQ_SUB socket types.

-

Further, PGM sockets are rate limited by default and incur a performance -penalty when used over a loopback interface. For details, refer to the -ZMQ_RATE, ZMQ_RECOVERY_IVL and ZMQ_MCAST_LOOP options documented in -zmq_setsockopt(3).

-
- - - -
-
Caution
-		The pgm transport implementation requires access to raw IP sockets. -Additional privileges may be required on some operating systems for this -operation. Applications not requiring direct interoperability with other PGM -implementations are encouraged to use the epgm transport instead which does -not require any special privileges.
-
-
-

ADDRESSING

-
-

A ØMQ address string consists of two parts as follows: -transport://endpoint. The transport part specifies the underlying -transport protocol to use. For the standard PGM protocol, transport shall be -set to pgm. For the "Encapsulated PGM" protocol transport shall be set to -epgm. The meaning of the endpoint part for both the pgm and epgm -transport is defined below.

-

Connecting a socket

-

When connecting a socket to a peer address using zmq_connect() with the pgm -or epgm transport, the endpoint shall be interpreted as an interface -followed by a semicolon, followed by a multicast address, followed by a colon -and a port number.

-

An interface may be specified by either of the following:

-
    -
  • -

    -The interface name as defined by the operating system. -

    -
    • -
  • -

    -The primary IPv4 address assigned to the interface, in it’s numeric - representation. -

    -
    • -
-
- - - -
-
Note
-		Interface names are not standardised in any way and should be assumed to -be arbitrary and platform dependent. On Win32 platforms no short interface -names exist, thus only the primary IPv4 address may be used to specify an -interface.
-
-

A multicast address is specified by an IPv4 multicast address in it’s numeric -representation.

-
-

WIRE FORMAT

-
-

Consecutive PGM datagrams are interpreted by ØMQ as a single continous stream -of data where ØMQ messages are not necessarily aligned with PGM datagram -boundaries and a single ØMQ message may span several PGM datagrams. This stream -of data consists of ØMQ messages encapsulated in frames as described in -zmq_tcp(7).

-

PGM datagram payload

-

The following ABNF grammar represents the payload of a single PGM datagram as -used by ØMQ:

-
-
-
datagram               = (offset data)
-offset                 = 2OCTET
-data                   = *OCTET
-
-

In order for late joining consumers to be able to identify message boundaries, -each PGM datagram payload starts with a 16-bit unsigned integer in network byte -order specifying either the offset of the first message frame in the datagram -or containing the value 0xFFFF if the datagram contains solely an -intermediate part of a larger message.

-

The following diagram illustrates the layout of a single PGM datagram payload:

-
-
-
+------------------+----------------------+
-| offset (16 bits) |         data         |
-+------------------+----------------------+
-
-

The following diagram further illustrates how three example ØMQ frames are laid -out in consecutive PGM datagram payloads:

-
-
-
First datagram payload
-+--------------+-------------+---------------------+
-| Frame offset |   Frame 1   |   Frame 2, part 1   |
-|    0x0000    | (Message 1) | (Message 2, part 1) |
-+--------------+-------------+---------------------+
-
-Second datagram payload
-+--------------+---------------------+
-| Frame offset |   Frame 2, part 2   |
-| 0xFFFF       | (Message 2, part 2) |
-+--------------+---------------------+
-
-Third datagram payload
-+--------------+----------------------------+-------------+
-| Frame offset |   Frame 2, final 8 bytes   |   Frame 3   |
-| 0x0008       | (Message 2, final 8 bytes) | (Message 3) |
-+--------------+----------------------------+-------------+
-
-
-

EXAMPLE

-
-
-
Connecting a socket
-
-
/* Connecting to the multicast address 239.192.1.1, port 5555, */
-/* using the first ethernet network interface on Linux */
-/* and the Encapsulated PGM protocol */
-rc = zmq_connect(socket, "epgm://eth0;239.192.1.1:5555");
-assert (rc == 0);
-/* Connecting to the multicast address 239.192.1.1, port 5555, */
-/* using the network interface with the address 192.168.1.1 */
-/* and the standard PGM protocol */
-rc = zmq_connect(socket, "pgm://192.168.1.1;239.192.1.1:5555");
-assert (rc == 0);
-
-
-

SEE ALSO

-
-

zmq_connect(3) -zmq_setsockopt(3) -zmq_tcp(7) -zmq_ipc(7) -zmq_inproc(7) -zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_pgm.txt b/doc/zmq_pgm.txt index 4017db2..72ae24f 100644 --- a/doc/zmq_pgm.txt +++ b/doc/zmq_pgm.txt @@ -24,7 +24,7 @@ The 'pgm' and 'epgm' transports can only be used with the 'ZMQ_PUB' and 'ZMQ_SUB' socket types. Further, PGM sockets are rate limited by default and incur a performance -penalty when used over a loopback interface. For details, refer to the +penalty when used over a loop-back interface. For details, refer to the 'ZMQ_RATE', 'ZMQ_RECOVERY_IVL' and 'ZMQ_MCAST_LOOP' options documented in linkzmq:zmq_setsockopt[3]. @@ -69,7 +69,7 @@ representation. WIRE FORMAT ----------- -Consecutive PGM datagrams are interpreted by 0MQ as a single continous stream +Consecutive PGM datagrams are interpreted by 0MQ as a single continuous stream of data where 0MQ messages are not necessarily aligned with PGM datagram boundaries and a single 0MQ message may span several PGM datagrams. This stream of data consists of 0MQ messages encapsulated in 'frames' as described in @@ -130,7 +130,7 @@ EXAMPLE .Connecting a socket ---- /* Connecting to the multicast address 239.192.1.1, port 5555, */ -/* using the first ethernet network interface on Linux */ +/* using the first Ethernet network interface on Linux */ /* and the Encapsulated PGM protocol */ rc = zmq_connect(socket, "epgm://eth0;239.192.1.1:5555"); assert (rc == 0); @@ -153,5 +153,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_poll.3 b/doc/zmq_poll.3 index 3f12c3b..a5d005c 100644 --- a/doc/zmq_poll.3 +++ b/doc/zmq_poll.3 @@ -2,12 +2,12 @@ .\" Title: zmq_poll .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_POLL" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_POLL" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -70,11 +70,11 @@ All 0MQ sockets passed to the \fIzmq_poll()\fR function must share the same 0MQ .sp .5v .RE .sp -For each \fBzmq_pollitem_t\fR item, \fIzmq_poll()\fR shall first clear the \fIrevents\fR member, and then indicate any requested events that have occured by setting the bit corresponding to the event condition in the \fIrevents\fR member\&. +For each \fBzmq_pollitem_t\fR item, \fIzmq_poll()\fR shall first clear the \fIrevents\fR member, and then indicate any requested events that have occurred by setting the bit corresponding to the event condition in the \fIrevents\fR member\&. .sp -If none of the requested events have occured on any \fBzmq_pollitem_t\fR item, \fIzmq_poll()\fR shall wait up to \fItimeout\fR microseconds for an event to occur on any of the requested items\&. If the value of \fItimeout\fR is 0, \fIzmq_poll()\fR shall return immediately\&. If the value of \fItimeout\fR is \-1, \fIzmq_poll()\fR shall block indefinitely until a requested event has occured on at least one \fBzmq_pollitem_t\fR\&. +If none of the requested events have occurred on any \fBzmq_pollitem_t\fR item, \fIzmq_poll()\fR shall wait \fItimeout\fR microseconds for an event to occur on any of the requested items\&. If the value of \fItimeout\fR is 0, \fIzmq_poll()\fR shall return immediately\&. If the value of \fItimeout\fR is \-1, \fIzmq_poll()\fR shall block indefinitely until a requested event has occurred on at least one \fBzmq_pollitem_t\fR\&. .sp -The \fIevents\fR and \fIrevents\fR members of \fBzmq_pollitem_t\fR are bitmasks constructed by OR\(cqing a combination of the following event flags: +The \fIevents\fR and \fIrevents\fR members of \fBzmq_pollitem_t\fR are bit masks constructed by OR\(cqing a combination of the following event flags: .PP \fBZMQ_POLLIN\fR .RS 4 @@ -134,33 +134,8 @@ The \fIzmq_poll()\fR function may be implemented or emulated using operating sys .SH "RETURN VALUE" .sp Upon successful completion, the \fIzmq_poll()\fR function shall return the number of \fBzmq_pollitem_t\fR structures with events signaled in \fIrevents\fR or 0 if no events have been signaled\&. Upon failure, \fIzmq_poll()\fR shall return \-1 and set \fIerrno\fR to one of the values defined below\&. -.if n \{\ -.sp -.\} -.RS 4 -.it 1 an-trap -.nr an-no-space-flag 1 -.nr an-break-flag 1 -.br -.ps +1 -\fBImportant\fR -.ps -1 -.br -.sp -The \fIzmq_poll()\fR function may return \fBbefore\fR the \fItimeout\fR period has expired even if no events have been signaled\&. -.sp .5v -.RE .SH "ERRORS" .PP -\fBEFAULT\fR -.RS 4 -At least one of the members of the -\fIitems\fR -array refers to a -\fIsocket\fR -belonging to a different application thread\&. -.RE -.PP \fBETERM\fR .RS 4 At least one of the members of the @@ -178,6 +153,11 @@ The provided \fIitems\fR was not valid (NULL)\&. .RE +.PP +\fBEINTR\fR +.RS 4 +The operation was interrupted by delivery of a signal before any events were available\&. +.RE .SH "EXAMPLE" .PP \fBPolling indefinitely for input events on both a 0MQ socket and a standard socket.\fR. @@ -210,7 +190,7 @@ assert (rc >= 0); Your operating system documentation for the \fIpoll()\fR system call\&. .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_poll.html b/doc/zmq_poll.html deleted file mode 100644 index 43882b1..0000000 --- a/doc/zmq_poll.html +++ /dev/null @@ -1,764 +0,0 @@ - - - - - -zmq_poll(3) - - - - - -
-

SYNOPSIS

-
-

int zmq_poll (zmq_pollitem_t *items, int nitems, long timeout);

-
-

DESCRIPTION

-
-

The zmq_poll() function provides a mechanism for applications to multiplex -input/output events in a level-triggered fashion over a set of sockets. Each -member of the array pointed to by the items argument is a zmq_pollitem_t -structure. The nitems argument specifies the number of items in the items -array. The zmq_pollitem_t structure is defined as follows:

-
-
-
typedef struct
-{
-    void *socket;
-    int fd;
-    short events;
-    short revents;
-} zmq_pollitem_t;
-
-

For each zmq_pollitem_t item, zmq_poll() shall examine either the ØMQ -socket referenced by socket or the standard socket specified by the file -descriptor fd, for the event(s) specified in events. If both socket and -fd are set in a single zmq_pollitem_t, the ØMQ socket referenced by -socket shall take precedence and the value of fd shall be ignored.

-
- - - -
-
Note
-		All ØMQ sockets passed to the zmq_poll() function must share the -same ØMQ context and must belong to the thread calling zmq_poll().
-
-

For each zmq_pollitem_t item, zmq_poll() shall first clear the revents -member, and then indicate any requested events that have occured by setting the -bit corresponding to the event condition in the revents member.

-

If none of the requested events have occured on any zmq_pollitem_t item, -zmq_poll() shall wait up to timeout microseconds for an event to occur on -any of the requested items. If the value of timeout is 0, zmq_poll() -shall return immediately. If the value of timeout is -1, zmq_poll() shall -block indefinitely until a requested event has occured on at least one -zmq_pollitem_t.

-

The events and revents members of zmq_pollitem_t are bitmasks constructed -by OR’ing a combination of the following event flags:

-
-
-ZMQ_POLLIN -
-
-

-For ØMQ sockets, at least one message may be received from the socket without -blocking. For standard sockets this is equivalent to the POLLIN flag of the -poll() system call and generally means that at least one byte of data may be -read from fd without blocking. -

-
-
-ZMQ_POLLOUT -
-
-

-For ØMQ sockets, at least one message may be sent to the socket without -blocking. For standard sockets this is equivalent to the POLLOUT flag of the -poll() system call and generally means that at least one byte of data may be -written to fd without blocking. -

-
-
-ZMQ_POLLERR -
-
-

-For standard sockets, this flag is passed through zmq_poll() to the -underlying poll() system call and generally means that some sort of error -condition is present on the socket specified by fd. For ØMQ sockets this flag -has no effect if set in events, and shall never be returned in revents by -zmq_poll(). -

-
-
-
- - - -
-
Note
-		The zmq_poll() function may be implemented or emulated using operating -system interfaces other than poll(), and as such may be subject to the limits -of those interfaces in ways not defined in this documentation.
-
-
-

RETURN VALUE

-
-

Upon successful completion, the zmq_poll() function shall return the number -of zmq_pollitem_t structures with events signaled in revents or 0 if no -events have been signaled. Upon failure, zmq_poll() shall return -1 and set -errno to one of the values defined below.

-
- - - -
-
Important
-		The zmq_poll() function may return before the timeout period -has expired even if no events have been signaled.
-
-
-

ERRORS

-
-
-
-EFAULT -
-
-

-At least one of the members of the items array refers to a socket belonging -to a different application thread. -

-
-
-ETERM -
-
-

-At least one of the members of the items array refers to a socket whose -associated ØMQ context was terminated. -

-
-
-EFAULT -
-
-

-The provided items was not valid (NULL). -

-
-
-
-

EXAMPLE

-
-
-
Polling indefinitely for input events on both a ØMQ socket and a standard socket.
-
-
zmq_pollitem_t items [2];
-/* First item refers to 0MQ socket 'socket' */
-items[0].socket = socket;
-items[0].events = ZMQ_POLLIN;
-/* Second item refers to standard socket 'fd' */
-items[1].socket = NULL;
-items[1].fd = fd;
-items[1].events = ZMQ_POLLIN;
-/* Poll for events indefinitely */
-int rc = zmq_poll (items, 2, -1);
-assert (rc >= 0);
-/* Returned events will be stored in items[].revents */
-
-
-

SEE ALSO

-
-

zmq_socket(3) -zmq_send(3) -zmq_recv(3) -zmq(7)

-

Your operating system documentation for the poll() system call.

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_poll.txt b/doc/zmq_poll.txt index fe2a209..26d7dac 100644 --- a/doc/zmq_poll.txt +++ b/doc/zmq_poll.txt @@ -40,17 +40,17 @@ NOTE: All 0MQ sockets passed to the _zmq_poll()_ function must share the same 0MQ 'context' and must belong to the thread calling _zmq_poll()_. For each *zmq_pollitem_t* item, _zmq_poll()_ shall first clear the 'revents' -member, and then indicate any requested events that have occured by setting the +member, and then indicate any requested events that have occurred by setting the bit corresponding to the event condition in the 'revents' member. -If none of the requested events have occured on any *zmq_pollitem_t* item, -_zmq_poll()_ shall wait up to 'timeout' microseconds for an event to occur on +If none of the requested events have occurred on any *zmq_pollitem_t* item, +_zmq_poll()_ shall wait 'timeout' microseconds for an event to occur on any of the requested items. If the value of 'timeout' is `0`, _zmq_poll()_ shall return immediately. If the value of 'timeout' is `-1`, _zmq_poll()_ shall -block indefinitely until a requested event has occured on at least one +block indefinitely until a requested event has occurred on at least one *zmq_pollitem_t*. -The 'events' and 'revents' members of *zmq_pollitem_t* are bitmasks constructed +The 'events' and 'revents' members of *zmq_pollitem_t* are bit masks constructed by OR'ing a combination of the following event flags: *ZMQ_POLLIN*:: @@ -84,20 +84,17 @@ of *zmq_pollitem_t* structures with events signaled in 'revents' or `0` if no events have been signaled. Upon failure, _zmq_poll()_ shall return `-1` and set 'errno' to one of the values defined below. -IMPORTANT: The _zmq_poll()_ function may return *before* the 'timeout' period -has expired even if no events have been signaled. - ERRORS ------ -*EFAULT*:: -At least one of the members of the 'items' array refers to a 'socket' belonging -to a different application thread. *ETERM*:: At least one of the members of the 'items' array refers to a 'socket' whose associated 0MQ 'context' was terminated. *EFAULT*:: The provided 'items' was not valid (NULL). +*EINTR*:: +The operation was interrupted by delivery of a signal before any events were +available. EXAMPLE @@ -131,5 +128,5 @@ Your operating system documentation for the _poll()_ system call. AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_queue.1 b/doc/zmq_queue.1 deleted file mode 100644 index 24f54ca..0000000 --- a/doc/zmq_queue.1 +++ /dev/null @@ -1,57 +0,0 @@ -'\" t -.\" Title: zmq_queue -.\" Author: [see the "AUTHORS" section] -.\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 -.\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 -.\" Language: English -.\" -.TH "ZMQ_QUEUE" "1" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" -.\" ----------------------------------------------------------------- -.\" * Define some portability stuff -.\" ----------------------------------------------------------------- -.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.\" http://bugs.debian.org/507673 -.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html -.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.ie \n(.g .ds Aq \(aq -.el .ds Aq ' -.\" ----------------------------------------------------------------- -.\" * set default formatting -.\" ----------------------------------------------------------------- -.\" disable hyphenation -.nh -.\" disable justification (adjust text to left margin only) -.ad l -.\" ----------------------------------------------------------------- -.\" * MAIN CONTENT STARTS HERE * -.\" ----------------------------------------------------------------- -.SH "NAME" -zmq_queue \- forwarding device for request\-reply messaging -.SH "SYNOPSIS" -.sp -To be written\&. -.SH "DESCRIPTION" -.sp -To be written\&. -.SH "OPTIONS" -.sp -To be written\&. -.SH "SEE ALSO" -.sp -\fBzmq\fR(7) -.SH "AUTHORS" -.sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. -.SH "NOTES" -.IP " 1." 4 -sustrik@250bpm.com -.RS 4 -\%mailto:sustrik@250bpm.com -.RE -.IP " 2." 4 -mato@kotelna.sk -.RS 4 -\%mailto:mato@kotelna.sk -.RE diff --git a/doc/zmq_queue.html b/doc/zmq_queue.html deleted file mode 100644 index c737eb8..0000000 --- a/doc/zmq_queue.html +++ /dev/null @@ -1,613 +0,0 @@ - - - - - -zmq_queue(1) - - - - - -
-

SYNOPSIS

-
-

To be written.

-
-

DESCRIPTION

-
-

To be written.

-
-

OPTIONS

-
-

To be written.

-
-

SEE ALSO

-
-

zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_queue.txt b/doc/zmq_queue.txt deleted file mode 100644 index a3f84f2..0000000 --- a/doc/zmq_queue.txt +++ /dev/null @@ -1,33 +0,0 @@ -zmq_queue(1) -============ - - -NAME ----- -zmq_queue - forwarding device for request-reply messaging - - -SYNOPSIS --------- -To be written. - - -DESCRIPTION ------------ -To be written. - - -OPTIONS -------- -To be written. - - -SEE ALSO --------- -linkzmq:zmq[7] - - -AUTHORS -------- -The 0MQ documentation was written by Martin Sustrik and -Martin Lucina . diff --git a/doc/zmq_recv.3 b/doc/zmq_recv.3 index 2a62efd..970d1ba 100644 --- a/doc/zmq_recv.3 +++ b/doc/zmq_recv.3 @@ -2,12 +2,12 @@ .\" Title: zmq_recv .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_RECV" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_RECV" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -95,6 +95,11 @@ The provided \fIsocket\fR was not valid (NULL)\&. .RE +.PP +\fBEINTR\fR +.RS 4 +The operation was interrupted by delivery of a signal before a message was available\&. +.RE .SH "EXAMPLE" .PP \fBReceiving a message from a socket\fR. @@ -148,7 +153,7 @@ do { \fBzmq_send\fR(3) \fBzmq_getsockopt\fR(3) \fBzmq_socket\fR(7) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_recv.html b/doc/zmq_recv.html deleted file mode 100644 index 16e5461..0000000 --- a/doc/zmq_recv.html +++ /dev/null @@ -1,729 +0,0 @@ - - - - - -zmq_recv(3) - - - - - -
-

SYNOPSIS

-
-

int zmq_recv (void *socket, zmq_msg_t *msg, int flags);

-
-

DESCRIPTION

-
-

The zmq_recv() function shall receive a message from the socket referenced by -the socket argument and store it in the message referenced by the msg -argument. Any content previously stored in msg shall be properly deallocated. -If there are no messages available on the specified socket the zmq_recv() -function shall block until the request can be satisfied. The flags argument -is a combination of the flags defined below:

-
-
-ZMQ_NOBLOCK -
-
-

-Specifies that the operation should be performed in non-blocking mode. If there -are no messages available on the specified socket, the zmq_recv() function -shall fail with errno set to EAGAIN. -

-
-
-

Multi-part messages

-

A ØMQ message is composed of 1 or more message parts; each message part is an -independent zmq_msg_t in its own right. ØMQ ensures atomic delivery of -messages; peers shall receive either all message parts of a message or none -at all.

-

The total number of message parts is unlimited.

-

An application wishing to determine if a message is composed of multiple parts -does so by retrieving the value of the ZMQ_RCVMORE socket option on the -socket it is receiving the message from. If there are no message parts to -follow, or if the message is not composed of multiple parts, ZMQ_RCVMORE -shall report a value of zero. Otherwise, ZMQ_RCVMORE shall report a value of -1, indicating that more message parts are to follow.

-
-

RETURN VALUE

-
-

The zmq_recv() function shall return zero if successful. Otherwise it shall -return -1 and set errno to one of the values defined below.

-
-

ERRORS

-
-
-
-EAGAIN -
-
-

-Non-blocking mode was requested and no messages are available at the moment. -

-
-
-ENOTSUP -
-
-

-The zmq_recv() operation is not supported by this socket type. -

-
-
-EFSM -
-
-

-The zmq_recv() operation cannot be performed on this socket at the moment due -to the socket not being in the appropriate state. This error may occur with -socket types that switch between several states, such as ZMQ_REP. See the -messaging patterns section of zmq_socket(3) for more information. -

-
-
-ETERM -
-
-

-The ØMQ context associated with the specified socket was terminated. -

-
-
-EFAULT -
-
-

-The provided socket was not valid (NULL). -

-
-
-
-

EXAMPLE

-
-
-
Receiving a message from a socket
-
-
/* Create an empty 0MQ message */
-zmq_msg_t msg;
-int rc = zmq_msg_init (&msg);
-assert (rc == 0);
-/* Block until a message is available to be received from socket */
-rc = zmq_recv (socket, &msg, 0);
-assert (rc == 0);
-/* Release message */
-zmq_msg_close (&msg);
-
-
-
Receiving a multi-part message
-
-
int64_t more;
-size_t more_size = sizeof more;
-do {
-    /* Create an empty 0MQ message to hold the message part */
-    zmq_msg_t part;
-    int rc = zmq_msg_init (&part);
-    assert (rc == 0);
-    /* Block until a message is available to be received from socket */
-    rc = zmq_recv (socket, &part, 0);
-    assert (rc == 0);
-    /* Determine if more message parts are to follow */
-    rc = zmq_getsockopt (socket, ZMQ_RCVMORE, &more, &more_size);
-    assert (rc == 0);
-    zmq_msg_close (&part);
-} while (more);
-
-
-

SEE ALSO

-
-

zmq_send(3) -zmq_getsockopt(3) -zmq_socket(7) -zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_recv.txt b/doc/zmq_recv.txt index dc60af6..1e6e65d 100644 --- a/doc/zmq_recv.txt +++ b/doc/zmq_recv.txt @@ -65,6 +65,9 @@ _messaging patterns_ section of linkzmq:zmq_socket[3] for more information. The 0MQ 'context' associated with the specified 'socket' was terminated. *EFAULT*:: The provided 'socket' was not valid (NULL). +*EINTR*:: +The operation was interrupted by delivery of a signal before a message was +available. EXAMPLE @@ -112,5 +115,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_send.3 b/doc/zmq_send.3 index 268911f..039d5f1 100644 --- a/doc/zmq_send.3 +++ b/doc/zmq_send.3 @@ -2,12 +2,12 @@ .\" Title: zmq_send .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_SEND" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_SEND" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -113,9 +113,14 @@ was terminated\&. \fBEFAULT\fR .RS 4 The provided -\fIcontext\fR +\fIsocket\fR was not valid (NULL)\&. .RE +.PP +\fBEINTR\fR +.RS 4 +The operation was interrupted by delivery of a signal before the message was sent\&. +.RE .SH "EXAMPLE" .PP \fBFilling in a message and sending it to a socket\fR. @@ -159,7 +164,7 @@ rc = zmq_send (socket, &part3, 0); \fBzmq_recv\fR(3) \fBzmq_socket\fR(7) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_send.html b/doc/zmq_send.html deleted file mode 100644 index 1e94c89..0000000 --- a/doc/zmq_send.html +++ /dev/null @@ -1,735 +0,0 @@ - - - - - -zmq_send(3) - - - - - -
-

SYNOPSIS

-
-

int zmq_send (void *socket, zmq_msg_t *msg, int flags);

-
-

DESCRIPTION

-
-

The zmq_send() function shall queue the message referenced by the msg -argument to be sent to the socket referenced by the socket argument. The -flags argument is a combination of the flags defined below:

-
-
-ZMQ_NOBLOCK -
-
-

-Specifies that the operation should be performed in non-blocking mode. If the -message cannot be queued on the socket, the zmq_send() function shall fail -with errno set to EAGAIN. -

-
-
-ZMQ_SNDMORE -
-
-

-Specifies that the message being sent is a multi-part message, and that further -message parts are to follow. Refer to the section regarding multi-part messages -below for a detailed description. -

-
-
-
- - - -
-
Note
-		A successful invocation of zmq_send() does not indicate that the -message has been transmitted to the network, only that it has been queued on -the socket and ØMQ has assumed responsibility for the message.
-
-

Multi-part messages

-

A ØMQ message is composed of 1 or more message parts; each message part is an -independent zmq_msg_t in its own right. ØMQ ensures atomic delivery of -messages; peers shall receive either all message parts of a message or none -at all.

-

The total number of message parts is unlimited.

-

An application wishing to send a multi-part message does so by specifying the -ZMQ_SNDMORE flag to zmq_send(). The presence of this flag indicates to ØMQ -that the message being sent is a multi-part message and that more message parts -are to follow. When the application wishes to send the final message part it -does so by calling zmq_send() without the ZMQ_SNDMORE flag; this indicates -that no more message parts are to follow.

-
-

RETURN VALUE

-
-

The zmq_send() function shall return zero if successful. Otherwise it shall -return -1 and set errno to one of the values defined below.

-
-

ERRORS

-
-
-
-EAGAIN -
-
-

-Non-blocking mode was requested and the message cannot be sent at the moment. -

-
-
-ENOTSUP -
-
-

-The zmq_send() operation is not supported by this socket type. -

-
-
-EFSM -
-
-

-The zmq_send() operation cannot be performed on this socket at the moment due -to the socket not being in the appropriate state. This error may occur with -socket types that switch between several states, such as ZMQ_REP. See the -messaging patterns section of zmq_socket(3) for more information. -

-
-
-ETERM -
-
-

-The ØMQ context associated with the specified socket was terminated. -

-
-
-EFAULT -
-
-

-The provided context was not valid (NULL). -

-
-
-
-

EXAMPLE

-
-
-
Filling in a message and sending it to a socket
-
-
/* Create a new message, allocating 6 bytes for message content */
-zmq_msg_t msg;
-int rc = zmq_msg_init_size (&msg, 6);
-assert (rc == 0);
-/* Fill in message content with 'AAAAAA' */
-memset (zmq_msg_data (&msg), 'A', 6);
-/* Send the message to the socket */
-rc = zmq_send (socket, &msg, 0);
-assert (rc == 0);
-
-
-
Sending a multi-part message
-
-
/* Send a multi-part message consisting of three parts to socket */
-rc = zmq_send (socket, &part1, ZMQ_SNDMORE);
-rc = zmq_send (socket, &part2, ZMQ_SNDMORE);
-/* Final part; no more parts to follow */
-rc = zmq_send (socket, &part3, 0);
-
-
-

SEE ALSO

-
-

zmq_recv(3) -zmq_socket(7) -zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_send.txt b/doc/zmq_send.txt index 793d1a8..87b3a3f 100644 --- a/doc/zmq_send.txt +++ b/doc/zmq_send.txt @@ -70,7 +70,10 @@ _messaging patterns_ section of linkzmq:zmq_socket[3] for more information. *ETERM*:: The 0MQ 'context' associated with the specified 'socket' was terminated. *EFAULT*:: -The provided 'context' was not valid (NULL). +The provided 'socket' was not valid (NULL). +*EINTR*:: +The operation was interrupted by delivery of a signal before the message was +sent. EXAMPLE @@ -107,5 +110,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_setsockopt.3 b/doc/zmq_setsockopt.3 index c6d0e96..094e946 100644 --- a/doc/zmq_setsockopt.3 +++ b/doc/zmq_setsockopt.3 @@ -2,12 +2,12 @@ .\" Title: zmq_setsockopt .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/20/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_SETSOCKOPT" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_SETSOCKOPT" "3" "03/20/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -32,6 +32,8 @@ zmq_setsockopt \- set 0MQ socket options .SH "SYNOPSIS" .sp \fBint zmq_setsockopt (void \fR\fB\fI*socket\fR\fR\fB, int \fR\fB\fIoption_name\fR\fR\fB, const void \fR\fB\fI*option_value\fR\fR\fB, size_t \fR\fB\fIoption_len\fR\fR\fB);\fR +.sp +Caution: All options, with the exception of ZMQ_SUBSCRIBE, ZMQ_UNSUBSCRIBE and ZMQ_LINGER, only take effect for subsequent socket bind/connects\&. .SH "DESCRIPTION" .sp The \fIzmq_setsockopt()\fR function shall set the option specified by the \fIoption_name\fR argument to the value pointed to by the \fIoption_value\fR argument for the 0MQ socket pointed to by the \fIsocket\fR argument\&. The \fIoption_len\fR argument is the size of the option value in bytes\&. @@ -166,7 +168,7 @@ T} .sp 1 .SS "ZMQ_IDENTITY: Set socket identity" .sp -The \fIZMQ_IDENTITY\fR option shall set the identity of the specified \fIsocket\fR\&. Socket identity determines if existing 0MQ infastructure (\fImessage queues\fR, \fIforwarding devices\fR) shall be identified with a specific application and persist across multiple runs of the application\&. +The \fIZMQ_IDENTITY\fR option shall set the identity of the specified \fIsocket\fR\&. Socket identity determines if existing 0MQ infrastructure (\fImessage queues\fR, \fIforwarding devices\fR) shall be identified with a specific application and persist across multiple runs of the application\&. .sp If the socket has no identity, each run of an application is completely separate from other runs\&. However, with identity set the socket shall re\-use any existing 0MQ infrastructure configured by the previous run(s)\&. Thus the application may receive messages that were sent in the meantime, \fImessage queue\fR limits shall be shared with previous run(s) and so on\&. .sp @@ -211,7 +213,7 @@ T} .sp The \fIZMQ_SUBSCRIBE\fR option shall establish a new message filter on a \fIZMQ_SUB\fR socket\&. Newly created \fIZMQ_SUB\fR sockets shall filter out all incoming messages, therefore you should call this option to establish an initial message filter\&. .sp -An empty \fIoption_value\fR of length zero shall subscribe to all incoming messages\&. A non\-empty \fIoption_value\fR shall subscribe to all messages beginning with the specified prefix\&. Mutiple filters may be attached to a single \fIZMQ_SUB\fR socket, in which case a message shall be accepted if it matches at least one filter\&. +An empty \fIoption_value\fR of length zero shall subscribe to all incoming messages\&. A non\-empty \fIoption_value\fR shall subscribe to all messages beginning with the specified prefix\&. Multiple filters may be attached to a single \fIZMQ_SUB\fR socket, in which case a message shall be accepted if it matches at least one filter\&. .TS tab(:); lt lt @@ -342,7 +344,7 @@ The \fIZMQ_RECOVERY_IVL\fR option shall set the recovery interval for multicast .ps -1 .br .sp -Excersize care when setting large recovery intervals as the data needed for recovery will be held in memory\&. For example, a 1 minute recovery interval at a data rate of 1Gbps requires a 7GB in\-memory buffer\&. +Exercise care when setting large recovery intervals as the data needed for recovery will be held in memory\&. For example, a 1 minute recovery interval at a data rate of 1Gbps requires a 7GB in\-memory buffer\&. .sp .5v .RE .TS @@ -381,9 +383,66 @@ all, when using multicast transports T} .TE .sp 1 -.SS "ZMQ_MCAST_LOOP: Control multicast loopback" +.SS "ZMQ_RECOVERY_IVL_MSEC: Set multicast recovery interval in milliseconds" +.sp +The \fIZMQ_RECOVERY_IVL_MSEC\fR option shall set the recovery interval, specified in milliseconds (ms) for multicast transports using the specified \fIsocket\fR\&. The recovery interval determines the maximum time in milliseconds that a receiver can be absent from a multicast group before unrecoverable data loss will occur\&. +.sp +A non\-zero value of the \fIZMQ_RECOVERY_IVL_MSEC\fR option will take precedence over the \fIZMQ_RECOVERY_IVL\fR option, but since the default for the \fIZMQ_RECOVERY_IVL_MSEC\fR is \-1, the default is to use the \fIZMQ_RECOVERY_IVL\fR option value\&. +.if n \{\ +.sp +.\} +.RS 4 +.it 1 an-trap +.nr an-no-space-flag 1 +.nr an-break-flag 1 +.br +.ps +1 +\fBCaution\fR +.ps -1 +.br .sp -The \fIZMQ_MCAST_LOOP\fR option shall control whether data sent via multicast transports using the specified \fIsocket\fR can also be received by the sending host via loopback\&. A value of zero disables the loopback functionality, while the default value of 1 enables the loopback functionality\&. Leaving multicast loopback enabled when it is not required can have a negative impact on performance\&. Where possible, disable \fIZMQ_MCAST_LOOP\fR in production environments\&. +Exercise care when setting large recovery intervals as the data needed for recovery will be held in memory\&. For example, a 1 minute recovery interval at a data rate of 1Gbps requires a 7GB in\-memory buffer\&. +.sp .5v +.RE +.TS +tab(:); +lt lt +lt lt +lt lt +lt lt. +T{ +.sp +Option value type +T}:T{ +.sp +int64_t +T} +T{ +.sp +Option value unit +T}:T{ +.sp +milliseconds +T} +T{ +.sp +Default value +T}:T{ +.sp +\-1 +T} +T{ +.sp +Applicable socket types +T}:T{ +.sp +all, when using multicast transports +T} +.TE +.sp 1 +.SS "ZMQ_MCAST_LOOP: Control multicast loop\-back" +.sp +The \fIZMQ_MCAST_LOOP\fR option shall control whether data sent via multicast transports using the specified \fIsocket\fR can also be received by the sending host via loop\-back\&. A value of zero disables the loop\-back functionality, while the default value of 1 enables the loop\-back functionality\&. Leaving multicast loop\-back enabled when it is not required can have a negative impact on performance\&. Where possible, disable \fIZMQ_MCAST_LOOP\fR in production environments\&. .TS tab(:); lt lt @@ -498,6 +557,230 @@ all T} .TE .sp 1 +.SS "ZMQ_LINGER: Set linger period for socket shutdown" +.sp +The \fIZMQ_LINGER\fR option shall set the linger period for the specified \fIsocket\fR\&. The linger period determines how long pending messages which have yet to be sent to a peer shall linger in memory after a socket is closed with \fBzmq_close\fR(3), and further affects the termination of the socket\(cqs context with \fBzmq_term\fR(3)\&. The following outlines the different behaviours: +.sp +.RS 4 +.ie n \{\ +\h'-04'\(bu\h'+03'\c +.\} +.el \{\ +.sp -1 +.IP \(bu 2.3 +.\} +The default value of +\fI\-1\fR +specifies an infinite linger period\&. Pending messages shall not be discarded after a call to +\fIzmq_close()\fR; attempting to terminate the socket\(cqs context with +\fIzmq_term()\fR +shall block until all pending messages have been sent to a peer\&. +.RE +.sp +.RS 4 +.ie n \{\ +\h'-04'\(bu\h'+03'\c +.\} +.el \{\ +.sp -1 +.IP \(bu 2.3 +.\} +The value of +\fI0\fR +specifies no linger period\&. Pending messages shall be discarded immediately when the socket is closed with +\fIzmq_close()\fR\&. +.RE +.sp +.RS 4 +.ie n \{\ +\h'-04'\(bu\h'+03'\c +.\} +.el \{\ +.sp -1 +.IP \(bu 2.3 +.\} +Positive values specify an upper bound for the linger period in milliseconds\&. Pending messages shall not be discarded after a call to +\fIzmq_close()\fR; attempting to terminate the socket\(cqs context with +\fIzmq_term()\fR +shall block until either all pending messages have been sent to a peer, or the linger period expires, after which any pending messages shall be discarded\&. +.TS +tab(:); +lt lt +lt lt +lt lt +lt lt. +T{ +Option value type +T}:T{ +int +T} +T{ +Option value unit +T}:T{ +milliseconds +T} +T{ +Default value +T}:T{ +\-1 (infinite) +T} +T{ +Applicable socket types +T}:T{ +all +T} +.TE +.sp 1 +.RE +.SS "ZMQ_RECONNECT_IVL: Set reconnection interval" +.sp +The \fIZMQ_RECONNECT_IVL\fR option shall set the initial reconnection interval for the specified \fIsocket\fR\&. The reconnection interval is the period 0MQ shall wait between attempts to reconnect disconnected peers when using connection\-oriented transports\&. +.if n \{\ +.sp +.\} +.RS 4 +.it 1 an-trap +.nr an-no-space-flag 1 +.nr an-break-flag 1 +.br +.ps +1 +\fBNote\fR +.ps -1 +.br +.sp +The reconnection interval may be randomized by 0MQ to prevent reconnection storms in topologies with a large number of peers per socket\&. +.sp .5v +.RE +.TS +tab(:); +lt lt +lt lt +lt lt +lt lt. +T{ +.sp +Option value type +T}:T{ +.sp +int +T} +T{ +.sp +Option value unit +T}:T{ +.sp +milliseconds +T} +T{ +.sp +Default value +T}:T{ +.sp +100 +T} +T{ +.sp +Applicable socket types +T}:T{ +.sp +all, only for connection\-oriented transports +T} +.TE +.sp 1 +.SS "ZMQ_RECONNECT_IVL_MAX: Set maximum reconnection interval" +.sp +The \fIZMQ_RECONNECT_IVL_MAX\fR option shall set the maximum reconnection interval for the specified \fIsocket\fR\&. This is the maximum period 0MQ shall wait between attempts to reconnect\&. On each reconnect attempt, the previous interval shall be doubled untill ZMQ_RECONNECT_IVL_MAX is reached\&. This allows for exponential backoff strategy\&. Default value means no exponential backoff is performed and reconnect interval calculations are only based on ZMQ_RECONNECT_IVL\&. +.if n \{\ +.sp +.\} +.RS 4 +.it 1 an-trap +.nr an-no-space-flag 1 +.nr an-break-flag 1 +.br +.ps +1 +\fBNote\fR +.ps -1 +.br +.sp +Values less than ZMQ_RECONNECT_IVL will be ignored\&. +.sp .5v +.RE +.TS +tab(:); +lt lt +lt lt +lt lt +lt lt. +T{ +.sp +Option value type +T}:T{ +.sp +int +T} +T{ +.sp +Option value unit +T}:T{ +.sp +milliseconds +T} +T{ +.sp +Default value +T}:T{ +.sp +0 (only use ZMQ_RECONNECT_IVL) +T} +T{ +.sp +Applicable socket types +T}:T{ +.sp +all, only for connection\-oriented transports +T} +.TE +.sp 1 +.SS "ZMQ_BACKLOG: Set maximum length of the queue of outstanding connections" +.sp +The \fIZMQ_BACKLOG\fR option shall set the maximum length of the queue of outstanding peer connections for the specified \fIsocket\fR; this only applies to connection\-oriented transports\&. For details refer to your operating system documentation for the \fIlisten\fR function\&. +.TS +tab(:); +lt lt +lt lt +lt lt +lt lt. +T{ +.sp +Option value type +T}:T{ +.sp +int +T} +T{ +.sp +Option value unit +T}:T{ +.sp +connections +T} +T{ +.sp +Default value +T}:T{ +.sp +100 +T} +T{ +.sp +Applicable socket types +T}:T{ +.sp +all, only for connection\-oriented transports\&. +T} +.TE +.sp 1 .SH "RETURN VALUE" .sp The \fIzmq_setsockopt()\fR function shall return zero if successful\&. Otherwise it shall return \-1 and set \fIerrno\fR to one of the values defined below\&. @@ -529,6 +812,11 @@ The provided \fIsocket\fR was not valid (NULL)\&. .RE +.PP +\fBEINTR\fR +.RS 4 +The operation was interrupted by delivery of a signal\&. +.RE .SH "EXAMPLE" .PP \fBSubscribing to messages on a ZMQ_SUB socket\fR. @@ -576,7 +864,7 @@ assert (rc); \fBzmq_getsockopt\fR(3) \fBzmq_socket\fR(3) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_setsockopt.html b/doc/zmq_setsockopt.html deleted file mode 100644 index 1e3db91..0000000 --- a/doc/zmq_setsockopt.html +++ /dev/null @@ -1,1277 +0,0 @@ - - - - - -zmq_setsockopt(3) - - - - - -
-

SYNOPSIS

-
-

int zmq_setsockopt (void *socket, int option_name, const void *option_value, size_t option_len);

-
-

DESCRIPTION

-
-

The zmq_setsockopt() function shall set the option specified by the -option_name argument to the value pointed to by the option_value argument -for the ØMQ socket pointed to by the socket argument. The option_len -argument is the size of the option value in bytes.

-

The following socket options can be set with the zmq_setsockopt() function:

-

ZMQ_HWM: Set high water mark

-

The ZMQ_HWM option shall set the high water mark for the specified socket. -The high water mark is a hard limit on the maximum number of outstanding -messages ØMQ shall queue in memory for any single peer that the specified -socket is communicating with.

-

If this limit has been reached the socket shall enter an exceptional state and -depending on the socket type, ØMQ shall take appropriate action such as -blocking or dropping sent messages. Refer to the individual socket descriptions -in zmq_socket(3) for details on the exact action taken for each socket -type.

-

The default ZMQ_HWM value of zero means "no limit".

-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-uint64_t -

-
-Option value unit -
-		 -

-messages -

-
-Default value -
-		 -

-0 -

-
-Applicable socket types -
-		 -

-all -

-
-

ZMQ_SWAP: Set disk offload size

-

The ZMQ_SWAP option shall set the disk offload (swap) size for the specified -socket. A socket which has ZMQ_SWAP set to a non-zero value may exceed it’s -high water mark; in this case outstanding messages shall be offloaded to -storage on disk rather than held in memory.

-

The value of ZMQ_SWAP defines the maximum size of the swap space in bytes.

-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-int64_t -

-
-Option value unit -
-		 -

-bytes -

-
-Default value -
-		 -

-0 -

-
-Applicable socket types -
-		 -

-all -

-
-

ZMQ_AFFINITY: Set I/O thread affinity

-

The ZMQ_AFFINITY option shall set the I/O thread affinity for newly created -connections on the specified socket.

-

Affinity determines which threads from the ØMQ I/O thread pool associated with -the socket’s context shall handle newly created connections. A value of zero -specifies no affinity, meaning that work shall be distributed fairly among all -ØMQ I/O threads in the thread pool. For non-zero values, the lowest bit -corresponds to thread 1, second lowest bit to thread 2 and so on. For example, -a value of 3 specifies that subsequent connections on socket shall be handled -exclusively by I/O threads 1 and 2.

-

See also zmq_init(3) for details on allocating the number of I/O -threads for a specific context.

-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-uint64_t -

-
-Option value unit -
-		 -

-N/A (bitmap) -

-
-Default value -
-		 -

-0 -

-
-Applicable socket types -
-		 -

-N/A -

-
-

ZMQ_IDENTITY: Set socket identity

-

The ZMQ_IDENTITY option shall set the identity of the specified socket. -Socket identity determines if existing ØMQ infastructure (message queues, -forwarding devices) shall be identified with a specific application and -persist across multiple runs of the application.

-

If the socket has no identity, each run of an application is completely -separate from other runs. However, with identity set the socket shall re-use -any existing ØMQ infrastructure configured by the previous run(s). Thus the -application may receive messages that were sent in the meantime, message -queue limits shall be shared with previous run(s) and so on.

-

Identity should be at least one byte and at most 255 bytes long. Identities -starting with binary zero are reserved for use by ØMQ infrastructure.

-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-binary data -

-
-Option value unit -
-		 -

-N/A -

-
-Default value -
-		 -

-NULL -

-
-Applicable socket types -
-		 -

-all -

-
-

ZMQ_SUBSCRIBE: Establish message filter

-

The ZMQ_SUBSCRIBE option shall establish a new message filter on a ZMQ_SUB -socket. Newly created ZMQ_SUB sockets shall filter out all incoming messages, -therefore you should call this option to establish an initial message filter.

-

An empty option_value of length zero shall subscribe to all incoming -messages. A non-empty option_value shall subscribe to all messages beginning -with the specified prefix. Mutiple filters may be attached to a single -ZMQ_SUB socket, in which case a message shall be accepted if it matches at -least one filter.

-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-binary data -

-
-Option value unit -
-		 -

-N/A -

-
-Default value -
-		 -

-N/A -

-
-Applicable socket types -
-		 -

-ZMQ_SUB -

-
-

ZMQ_UNSUBSCRIBE: Remove message filter

-

The ZMQ_UNSUBSCRIBE option shall remove an existing message filter on a -ZMQ_SUB socket. The filter specified must match an existing filter previously -established with the ZMQ_SUBSCRIBE option. If the socket has several -instances of the same filter attached the ZMQ_UNSUBSCRIBE option shall remove -only one instance, leaving the rest in place and functional.

-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-binary data -

-
-Option value unit -
-		 -

-N/A -

-
-Default value -
-		 -

-N/A -

-
-Applicable socket types -
-		 -

-ZMQ_SUB -

-
-

ZMQ_RATE: Set multicast data rate

-

The ZMQ_RATE option shall set the maximum send or receive data rate for -multicast transports such as zmq_pgm(7) using the specified socket.

-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-int64_t -

-
-Option value unit -
-		 -

-kilobits per second -

-
-Default value -
-		 -

-100 -

-
-Applicable socket types -
-		 -

-all, when using multicast transports -

-
-

ZMQ_RECOVERY_IVL: Set multicast recovery interval

-

The ZMQ_RECOVERY_IVL option shall set the recovery interval for multicast -transports using the specified socket. The recovery interval determines the -maximum time in seconds that a receiver can be absent from a multicast group -before unrecoverable data loss will occur.

-
- - - -
-
Caution
-		Excersize care when setting large recovery intervals as the data -needed for recovery will be held in memory. For example, a 1 minute recovery -interval at a data rate of 1Gbps requires a 7GB in-memory buffer.
-
-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-int64_t -

-
-Option value unit -
-		 -

-seconds -

-
-Default value -
-		 -

-10 -

-
-Applicable socket types -
-		 -

-all, when using multicast transports -

-
-

ZMQ_MCAST_LOOP: Control multicast loopback

-

The ZMQ_MCAST_LOOP option shall control whether data sent via multicast -transports using the specified socket can also be received by the sending -host via loopback. A value of zero disables the loopback functionality, while -the default value of 1 enables the loopback functionality. Leaving multicast -loopback enabled when it is not required can have a negative impact on -performance. Where possible, disable ZMQ_MCAST_LOOP in production -environments.

-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-int64_t -

-
-Option value unit -
-		 -

-boolean -

-
-Default value -
-		 -

-1 -

-
-Applicable socket types -
-		 -

-all, when using multicast transports -

-
-

ZMQ_SNDBUF: Set kernel transmit buffer size

-

The ZMQ_SNDBUF option shall set the underlying kernel transmit buffer size -for the socket to the specified size in bytes. A value of zero means leave -the OS default unchanged. For details please refer to your operating system -documentation for the SO_SNDBUF socket option.

-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-uint64_t -

-
-Option value unit -
-		 -

-bytes -

-
-Default value -
-		 -

-0 -

-
-Applicable socket types -
-		 -

-all -

-
-

ZMQ_RCVBUF: Set kernel receive buffer size

-

The ZMQ_RCVBUF option shall set the underlying kernel receive buffer size for -the socket to the specified size in bytes. A value of zero means leave the -OS default unchanged. For details refer to your operating system documentation -for the SO_RCVBUF socket option.

-
- - - - - - - - - - - - - - - - -
-Option value type -
-		 -

-uint64_t -

-
-Option value unit -
-		 -

-bytes -

-
-Default value -
-		 -

-0 -

-
-Applicable socket types -
-		 -

-all -

-
-
-

RETURN VALUE

-
-

The zmq_setsockopt() function shall return zero if successful. Otherwise it -shall return -1 and set errno to one of the values defined below.

-
-

ERRORS

-
-
-
-EINVAL -
-
-

-The requested option option_name is unknown, or the requested option_len or -option_value is invalid. -

-
-
-ETERM -
-
-

-The ØMQ context associated with the specified socket was terminated. -

-
-
-EFAULT -
-
-

-The provided socket was not valid (NULL). -

-
-
-
-

EXAMPLE

-
-
-
Subscribing to messages on a ZMQ_SUB socket
-
-
/* Subscribe to all messages */
-rc = zmq_setsockopt (socket, ZMQ_SUBSCRIBE, "", 0);
-assert (rc == 0);
-/* Subscribe to messages prefixed with "ANIMALS.CATS" */
-rc = zmq_setsockopt (socket, ZMQ_SUBSCRIBE, "ANIMALS.CATS", 12);
-
-
-
Setting I/O thread affinity
-
-
int64_t affinity;
-/* Incoming connections on TCP port 5555 shall be handled by I/O thread 1 */
-affinity = 1;
-rc = zmq_setsockopt (socket, ZMQ_AFFINITY, &affinity, sizeof affinity);
-assert (rc);
-rc = zmq_bind (socket, "tcp://lo:5555");
-assert (rc);
-/* Incoming connections on TCP port 5556 shall be handled by I/O thread 2 */
-affinity = 2;
-rc = zmq_setsockopt (socket, ZMQ_AFFINITY, &affinity, sizeof affinity);
-assert (rc);
-rc = zmq_bind (socket, "tcp://lo:5556");
-assert (rc);
-
-
-

SEE ALSO

-
-

zmq_getsockopt(3) -zmq_socket(3) -zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_setsockopt.txt b/doc/zmq_setsockopt.txt index 1b551c6..8022568 100644 --- a/doc/zmq_setsockopt.txt +++ b/doc/zmq_setsockopt.txt @@ -12,6 +12,8 @@ SYNOPSIS -------- *int zmq_setsockopt (void '*socket', int 'option_name', const void '*option_value', size_t 'option_len');* +Caution: All options, with the exception of ZMQ_SUBSCRIBE, ZMQ_UNSUBSCRIBE and +ZMQ_LINGER, only take effect for subsequent socket bind/connects. DESCRIPTION ----------- @@ -87,7 +89,7 @@ Applicable socket types:: N/A ZMQ_IDENTITY: Set socket identity ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The 'ZMQ_IDENTITY' option shall set the identity of the specified 'socket'. -Socket identity determines if existing 0MQ infastructure (_message queues_, +Socket identity determines if existing 0MQ infrastructure (_message queues_, _forwarding devices_) shall be identified with a specific application and persist across multiple runs of the application. @@ -115,7 +117,7 @@ therefore you should call this option to establish an initial message filter. An empty 'option_value' of length zero shall subscribe to all incoming messages. A non-empty 'option_value' shall subscribe to all messages beginning -with the specified prefix. Mutiple filters may be attached to a single +with the specified prefix. Multiple filters may be attached to a single 'ZMQ_SUB' socket, in which case a message shall be accepted if it matches at least one filter. @@ -160,7 +162,7 @@ transports using the specified 'socket'. The recovery interval determines the maximum time in seconds that a receiver can be absent from a multicast group before unrecoverable data loss will occur. -CAUTION: Excersize care when setting large recovery intervals as the data +CAUTION: Exercise care when setting large recovery intervals as the data needed for recovery will be held in memory. For example, a 1 minute recovery interval at a data rate of 1Gbps requires a 7GB in-memory buffer. @@ -171,13 +173,37 @@ Default value:: 10 Applicable socket types:: all, when using multicast transports -ZMQ_MCAST_LOOP: Control multicast loopback -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +ZMQ_RECOVERY_IVL_MSEC: Set multicast recovery interval in milliseconds +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The 'ZMQ_RECOVERY_IVL_MSEC' option shall set the recovery interval, specified +in milliseconds (ms) for multicast transports using the specified 'socket'. +The recovery interval determines the maximum time in milliseconds that a +receiver can be absent from a multicast group before unrecoverable data loss +will occur. + +A non-zero value of the 'ZMQ_RECOVERY_IVL_MSEC' option will take precedence +over the 'ZMQ_RECOVERY_IVL' option, but since the default for the +'ZMQ_RECOVERY_IVL_MSEC' is -1, the default is to use the 'ZMQ_RECOVERY_IVL' +option value. + +CAUTION: Exercise care when setting large recovery intervals as the data +needed for recovery will be held in memory. For example, a 1 minute recovery +interval at a data rate of 1Gbps requires a 7GB in-memory buffer. + +[horizontal] +Option value type:: int64_t +Option value unit:: milliseconds +Default value:: -1 +Applicable socket types:: all, when using multicast transports + + +ZMQ_MCAST_LOOP: Control multicast loop-back +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The 'ZMQ_MCAST_LOOP' option shall control whether data sent via multicast transports using the specified 'socket' can also be received by the sending -host via loopback. A value of zero disables the loopback functionality, while -the default value of 1 enables the loopback functionality. Leaving multicast -loopback enabled when it is not required can have a negative impact on +host via loop-back. A value of zero disables the loop-back functionality, while +the default value of 1 enables the loop-back functionality. Leaving multicast +loop-back enabled when it is not required can have a negative impact on performance. Where possible, disable 'ZMQ_MCAST_LOOP' in production environments. @@ -216,6 +242,85 @@ Default value:: 0 Applicable socket types:: all +ZMQ_LINGER: Set linger period for socket shutdown +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The 'ZMQ_LINGER' option shall set the linger period for the specified 'socket'. +The linger period determines how long pending messages which have yet to be +sent to a peer shall linger in memory after a socket is closed with +linkzmq:zmq_close[3], and further affects the termination of the socket's +context with linkzmq:zmq_term[3]. The following outlines the different +behaviours: + +* The default value of '-1' specifies an infinite linger period. Pending + messages shall not be discarded after a call to _zmq_close()_; attempting to + terminate the socket's context with _zmq_term()_ shall block until all + pending messages have been sent to a peer. + +* The value of '0' specifies no linger period. Pending messages shall be + discarded immediately when the socket is closed with _zmq_close()_. + +* Positive values specify an upper bound for the linger period in milliseconds. + Pending messages shall not be discarded after a call to _zmq_close()_; + attempting to terminate the socket's context with _zmq_term()_ shall block + until either all pending messages have been sent to a peer, or the linger + period expires, after which any pending messages shall be discarded. + +[horizontal] +Option value type:: int +Option value unit:: milliseconds +Default value:: -1 (infinite) +Applicable socket types:: all + + +ZMQ_RECONNECT_IVL: Set reconnection interval +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The 'ZMQ_RECONNECT_IVL' option shall set the initial reconnection interval for +the specified 'socket'. The reconnection interval is the period 0MQ +shall wait between attempts to reconnect disconnected peers when using +connection-oriented transports. + +NOTE: The reconnection interval may be randomized by 0MQ to prevent +reconnection storms in topologies with a large number of peers per socket. + +[horizontal] +Option value type:: int +Option value unit:: milliseconds +Default value:: 100 +Applicable socket types:: all, only for connection-oriented transports + + +ZMQ_RECONNECT_IVL_MAX: Set maximum reconnection interval +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The 'ZMQ_RECONNECT_IVL_MAX' option shall set the maximum reconnection interval +for the specified 'socket'. This is the maximum period 0MQ shall wait between +attempts to reconnect. On each reconnect attempt, the previous interval shall be +doubled untill ZMQ_RECONNECT_IVL_MAX is reached. This allows for exponential +backoff strategy. Default value means no exponential backoff is performed and +reconnect interval calculations are only based on ZMQ_RECONNECT_IVL. + +NOTE: Values less than ZMQ_RECONNECT_IVL will be ignored. + +[horizontal] +Option value type:: int +Option value unit:: milliseconds +Default value:: 0 (only use ZMQ_RECONNECT_IVL) +Applicable socket types:: all, only for connection-oriented transports + + +ZMQ_BACKLOG: Set maximum length of the queue of outstanding connections +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The 'ZMQ_BACKLOG' option shall set the maximum length of the queue of +outstanding peer connections for the specified 'socket'; this only applies to +connection-oriented transports. For details refer to your operating system +documentation for the 'listen' function. + +[horizontal] +Option value type:: int +Option value unit:: connections +Default value:: 100 +Applicable socket types:: all, only for connection-oriented transports. + + RETURN VALUE ------------ The _zmq_setsockopt()_ function shall return zero if successful. Otherwise it @@ -231,6 +336,8 @@ _option_value_ is invalid. The 0MQ 'context' associated with the specified 'socket' was terminated. *EFAULT*:: The provided 'socket' was not valid (NULL). +*EINTR*:: +The operation was interrupted by delivery of a signal. EXAMPLE @@ -271,5 +378,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_socket.3 b/doc/zmq_socket.3 index b8dc539..000cb0f 100644 --- a/doc/zmq_socket.3 +++ b/doc/zmq_socket.3 @@ -2,12 +2,12 @@ .\" Title: zmq_socket .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/20/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_SOCKET" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_SOCKET" "3" "03/20/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -44,10 +44,16 @@ interface to either connection\-oriented reliable byte streams (SOCK_STREAM), or \fImessage queue\fR, with the exact queueing semantics depending on the socket type in use\&. Where conventional sockets transfer streams of bytes or discrete datagrams, 0MQ sockets transfer discrete \fImessages\fR\&. .sp -0MQ sockets being \fIasynchronous\fR means that the timings of the physical connection setup and teardown, reconnect and effective delivery are transparent to the user and organized by 0MQ itself\&. Further, messages may be \fIqueued\fR in the event that a peer is unavailable to receive them\&. +0MQ sockets being \fIasynchronous\fR means that the timings of the physical connection setup and tear down, reconnect and effective delivery are transparent to the user and organized by 0MQ itself\&. Further, messages may be \fIqueued\fR in the event that a peer is unavailable to receive them\&. .sp Conventional sockets allow only strict one\-to\-one (two peers), many\-to\-one (many clients, one server), or in some cases one\-to\-many (multicast) relationships\&. With the exception of \fIZMQ_PAIR\fR, 0MQ sockets may be connected \fBto multiple endpoints\fR using \fIzmq_connect()\fR, while simultaneously accepting incoming connections \fBfrom multiple endpoints\fR bound to the socket using \fIzmq_bind()\fR, thus allowing many\-to\-many relationships\&. .PP +\fBThread safety\fR. 0MQ +\fIsockets\fR +are +\fInot\fR +thread safe\&. Applications MUST NOT use a socket from multiple threads except after migrating a socket from one thread to another with a "full fence" memory barrier\&. +.PP \fBSocket types\fR. The following sections present the socket types defined by 0MQ, grouped by the general \fImessaging pattern\fR which is built from related socket types\&. @@ -134,7 +140,7 @@ T} \fBZMQ_REP\fR .RS 4 .sp -A socket of type \fIZMQ_REP\fR is used by a \fIservice\fR to receive requests from and send replies to a \fIclient\fR\&. This socket type allows only an alternating sequence of \fIzmq_recv(request)\fR and subsequent \fIzmq_send(reply)\fR calls\&. Each request received is fair\-queued from among all \fIclients\fR, and each reply sent is routed to the \fIclient\fR that issued the last request\&. +A socket of type \fIZMQ_REP\fR is used by a \fIservice\fR to receive requests from and send replies to a \fIclient\fR\&. This socket type allows only an alternating sequence of \fIzmq_recv(request)\fR and subsequent \fIzmq_send(reply)\fR calls\&. Each request received is fair\-queued from among all \fIclients\fR, and each reply sent is routed to the \fIclient\fR that issued the last request\&. If the original requester doesn\(cqt exist any more the reply is silently discarded\&. .sp When a \fIZMQ_REP\fR socket enters an exceptional state due to having reached the high water mark for a \fIclient\fR, then any replies sent to the \fIclient\fR in question shall be dropped until the exceptional state ends\&. .sp @@ -181,7 +187,7 @@ Fair\-queued T} T{ .sp -Outgoing routing stratagy +Outgoing routing strategy T}:T{ .sp Last peer @@ -202,20 +208,22 @@ T} .nr an-break-flag 1 .br .ps +1 -\fBZMQ_XREQ\fR +\fBZMQ_DEALER\fR .RS 4 .sp -A socket of type \fIZMQ_XREQ\fR is an advanced pattern used for extending request/reply sockets\&. Each message sent is load\-balanced among all connected peers, and each message received is fair\-queued from all connected peers\&. +A socket of type \fIZMQ_DEALER\fR is an advanced pattern used for extending request/reply sockets\&. Each message sent is load\-balanced among all connected peers, and each message received is fair\-queued from all connected peers\&. .sp -When a \fIZMQ_XREQ\fR socket enters an exceptional state due to having reached the high water mark for all peers, or if there are no peers at all, then any \fBzmq_send\fR(3) operations on the socket shall block until the exceptional state ends or at least one peer becomes available for sending; messages are not discarded\&. +Previously this socket was called \fIZMQ_XREQ\fR and that name remains available for backwards compatibility\&. .sp -When a \fIZMQ_XREQ\fR socket is connected to a \fIZMQ_REP\fR socket each message sent must consist of an empty message part, the \fIdelimiter\fR, followed by one or more \fIbody parts\fR\&. +When a \fIZMQ_DEALER\fR socket enters an exceptional state due to having reached the high water mark for all peers, or if there are no peers at all, then any \fBzmq_send\fR(3) operations on the socket shall block until the exceptional state ends or at least one peer becomes available for sending; messages are not discarded\&. +.sp +When a \fIZMQ_DEALER\fR socket is connected to a \fIZMQ_REP\fR socket each message sent must consist of an empty message part, the \fIdelimiter\fR, followed by one or more \fIbody parts\fR\&. .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br -.B Table\ \&3.\ \&Summary of ZMQ_XREQ characteristics +.B Table\ \&3.\ \&Summary of ZMQ_DEALER characteristics .TS tab(:); lt lt @@ -229,7 +237,7 @@ T{ Compatible peer sockets T}:T{ .sp -\fIZMQ_XREP\fR, \fIZMQ_REP\fR +\fIZMQ_ROUTER\fR, \fIZMQ_REP\fR T} T{ .sp @@ -275,20 +283,22 @@ T} .nr an-break-flag 1 .br .ps +1 -\fBZMQ_XREP\fR +\fBZMQ_ROUTER\fR .RS 4 .sp -A socket of type \fIZMQ_XREP\fR is an advanced pattern used for extending request/reply sockets\&. When receiving messages a \fIZMQ_XREP\fR socket shall prepend a message part containing the \fIidentity\fR of the originating peer to the message before passing it to the application\&. Messages received are fair\-queued from among all connected peers\&. When sending messages a \fIZMQ_XREP\fR socket shall remove the first part of the message and use it to determine the \fIidentity\fR of the peer the message shall be routed to\&. +A socket of type \fIZMQ_ROUTER\fR is an advanced pattern used for extending request/reply sockets\&. When receiving messages a \fIZMQ_ROUTER\fR socket shall prepend a message part containing the \fIidentity\fR of the originating peer to the message before passing it to the application\&. Messages received are fair\-queued from among all connected peers\&. When sending messages a \fIZMQ_ROUTER\fR socket shall remove the first part of the message and use it to determine the \fIidentity\fR of the peer the message shall be routed to\&. If the peer does not exist anymore the message shall be silently discarded\&. +.sp +Previously this socket was called \fIZMQ_XREP\fR and that name remains available for backwards compatibility\&. .sp -When a \fIZMQ_XREP\fR socket enters an exceptional state due to having reached the high water mark for all peers, or if there are no peers at all, then any messages sent to the socket shall be dropped until the exceptional state ends\&. Likewise, any messages routed to a non\-existent peer or a peer for which the individual high water mark has been reached shall also be dropped\&. +When a \fIZMQ_ROUTER\fR socket enters an exceptional state due to having reached the high water mark for all peers, or if there are no peers at all, then any messages sent to the socket shall be dropped until the exceptional state ends\&. Likewise, any messages routed to a non\-existent peer or a peer for which the individual high water mark has been reached shall also be dropped\&. .sp -When a \fIZMQ_REQ\fR socket is connected to a \fIZMQ_XREP\fR socket, in addition to the \fIidentity\fR of the originating peer each message received shall contain an empty \fIdelimiter\fR message part\&. Hence, the entire structure of each received message as seen by the application becomes: one or more \fIidentity\fR parts, \fIdelimiter\fR part, one or more \fIbody parts\fR\&. When sending replies to a \fIZMQ_REQ\fR socket the application must include the \fIdelimiter\fR part\&. +When a \fIZMQ_REQ\fR socket is connected to a \fIZMQ_ROUTER\fR socket, in addition to the \fIidentity\fR of the originating peer each message received shall contain an empty \fIdelimiter\fR message part\&. Hence, the entire structure of each received message as seen by the application becomes: one or more \fIidentity\fR parts, \fIdelimiter\fR part, one or more \fIbody parts\fR\&. When sending replies to a \fIZMQ_REQ\fR socket the application must include the \fIdelimiter\fR part\&. .sp .it 1 an-trap .nr an-no-space-flag 1 .nr an-break-flag 1 .br -.B Table\ \&4.\ \&Summary of ZMQ_XREP characteristics +.B Table\ \&4.\ \&Summary of ZMQ_ROUTER characteristics .TS tab(:); lt lt @@ -302,7 +312,7 @@ T{ Compatible peer sockets T}:T{ .sp -\fIZMQ_XREQ\fR, \fIZMQ_REQ\fR +\fIZMQ_DEALER\fR, \fIZMQ_REQ\fR T} T{ .sp @@ -344,7 +354,7 @@ T} .RE .SS "Publish\-subscribe pattern" .sp -The publish\-subscribe pattern is used for one\-to\-many distribution of data from a single \fIpublisher\fR to multiple \fIsubscribers\fR in a fanout fashion\&. +The publish\-subscribe pattern is used for one\-to\-many distribution of data from a single \fIpublisher\fR to multiple \fIsubscribers\fR in a fan out fashion\&. .sp .it 1 an-trap .nr an-no-space-flag 1 @@ -354,9 +364,9 @@ The publish\-subscribe pattern is used for one\-to\-many distribution of data fr \fBZMQ_PUB\fR .RS 4 .sp -A socket of type \fIZMQ_PUB\fR is used by a \fIpublisher\fR to distribute data\&. Messages sent are distributed in a fanout fashion to all connected peers\&. The \fBzmq_recv\fR(3) function is not implemented for this socket type\&. +A socket of type \fIZMQ_PUB\fR is used by a \fIpublisher\fR to distribute data\&. Messages sent are distributed in a fan out fashion to all connected peers\&. The \fBzmq_recv\fR(3) function is not implemented for this socket type\&. .sp -When a \fIZMQ_PUB\fR socket enters an exceptional state due to having reached the high water mark for a \fIsubscriber\fR, then any messages that would be sent to the \fIsubscriber\fR in question shall instead be dropped until the exceptional state ends\&. +When a \fIZMQ_PUB\fR socket enters an exceptional state due to having reached the high water mark for a \fIsubscriber\fR, then any messages that would be sent to the \fIsubscriber\fR in question shall instead be dropped until the exceptional state ends\&. The \fIzmq_send()\fR function shall never block for this socket type\&. .sp .it 1 an-trap .nr an-no-space-flag 1 @@ -404,7 +414,7 @@ T{ Outgoing routing strategy T}:T{ .sp -Fanout +Fan out T} T{ .sp @@ -480,7 +490,7 @@ T{ ZMQ_HWM option action T}:T{ .sp -N/A +Drop T} .TE .sp 1 @@ -634,7 +644,7 @@ T} .RE .SS "Exclusive pair pattern" .sp -The exclusive pair is an advanced pattern used for communicating exclusively between two peers\&. +The exclusive pair pattern is used to connect a peer to precisely one other peer\&. This pattern is used for inter\-thread communication across the inproc transport\&. .sp .it 1 an-trap .nr an-no-space-flag 1 @@ -660,7 +670,7 @@ When a \fIZMQ_PAIR\fR socket enters an exceptional state due to having reached t .ps -1 .br .sp -\fIZMQ_PAIR\fR sockets are experimental, and are currently missing several features such as auto\-reconnection\&. +\fIZMQ_PAIR\fR sockets are designed for inter\-thread communication across the \fBzmq_inproc\fR(7) transport and do not implement functionality such as auto\-reconnection\&. \fIZMQ_PAIR\fR sockets are considered experimental and may have other missing or broken aspects\&. .sp .5v .RE .sp @@ -734,25 +744,23 @@ The requested socket is invalid\&. .RE .PP -\fBEMTHREAD\fR -.RS 4 -The maximum number of sockets within this -\fIcontext\fR -has been exceeded\&. -.RE -.PP \fBEFAULT\fR .RS 4 The provided \fIcontext\fR was not valid (NULL)\&. .RE +.PP +\fBETERM\fR +.RS 4 +The context specified was terminated\&. +.RE .SH "SEE ALSO" .sp -\fBzmq_init\fR(3) \fBzmq_setsockopt\fR(3) \fBzmq_bind\fR(3) \fBzmq_connect\fR(3) \fBzmq_send\fR(3) \fBzmq_recv\fR(3) \fBzmq\fR(7) +\fBzmq_init\fR(3) \fBzmq_setsockopt\fR(3) \fBzmq_bind\fR(3) \fBzmq_connect\fR(3) \fBzmq_send\fR(3) \fBzmq_recv\fR(3) \fBzmq_inproc\fR(7) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_socket.html b/doc/zmq_socket.html deleted file mode 100644 index 50f5844..0000000 --- a/doc/zmq_socket.html +++ /dev/null @@ -1,1403 +0,0 @@ - - - - - -zmq_socket(3) - - - - - -
-

SYNOPSIS

-
-

void *zmq_socket (void *context, int type);

-
-

DESCRIPTION

-
-

The zmq_socket() function shall create a ØMQ socket within the specified -context and return an opaque handle to the newly created socket. The type -argument specifies the socket type, which determines the semantics of -communication over the socket.

-

The newly created socket is initially unbound, and not associated with any -endpoints. In order to establish a message flow a socket must first be -connected to at least one endpoint with zmq_connect(3), or at least one -endpoint must be created for accepting incoming connections with -zmq_bind(3).

-
Key differences to conventional sockets

Generally speaking, conventional sockets present a synchronous interface to -either connection-oriented reliable byte streams (SOCK_STREAM), or -connection-less unreliable datagrams (SOCK_DGRAM). In comparison, ØMQ sockets -present an abstraction of an asynchronous message queue, with the exact -queueing semantics depending on the socket type in use. Where conventional -sockets transfer streams of bytes or discrete datagrams, ØMQ sockets transfer -discrete messages.

-

ØMQ sockets being asynchronous means that the timings of the physical -connection setup and teardown, reconnect and effective delivery are transparent -to the user and organized by ØMQ itself. Further, messages may be queued in -the event that a peer is unavailable to receive them.

-

Conventional sockets allow only strict one-to-one (two peers), many-to-one -(many clients, one server), or in some cases one-to-many (multicast) -relationships. With the exception of ZMQ_PAIR, ØMQ sockets may be connected -to multiple endpoints using zmq_connect(), while simultaneously accepting -incoming connections from multiple endpoints bound to the socket using -zmq_bind(), thus allowing many-to-many relationships.

-
Socket types

The following sections present the socket types defined by ØMQ, grouped by the -general messaging pattern which is built from related socket types.

-

Request-reply pattern

-

The request-reply pattern is used for sending requests from a client to one -or more instances of a service, and receiving subsequent replies to each -request sent.

-

ZMQ_REQ

-

A socket of type ZMQ_REQ is used by a client to send requests to and -receive replies from a service. This socket type allows only an alternating -sequence of zmq_send(request) and subsequent zmq_recv(reply) calls. Each -request sent is load-balanced among all services, and each reply received is -matched with the last issued request.

-

When a ZMQ_REQ socket enters an exceptional state due to having reached the -high water mark for all services, or if there are no services at all, then -any zmq_send(3) operations on the socket shall block until the -exceptional state ends or at least one service becomes available for sending; -messages are not discarded.

-
Summary of ZMQ_REQ characteristics
- - - - - - - - - - - - - - - - - - - - - - - - -
-Compatible peer sockets -
-		 -

-ZMQ_REP -

-
-Direction -
-		 -

-Bidirectional -

-
-Send/receive pattern -
-		 -

-Send, Receive, Send, Receive, … -

-
-Outgoing routing strategy -
-		 -

-Load-balanced -

-
-Incoming routing strategy -
-		 -

-Last peer -

-
-ZMQ_HWM option action -
-		 -

-Block -

-
-

ZMQ_REP

-

A socket of type ZMQ_REP is used by a service to receive requests from and -send replies to a client. This socket type allows only an alternating -sequence of zmq_recv(request) and subsequent zmq_send(reply) calls. Each -request received is fair-queued from among all clients, and each reply sent -is routed to the client that issued the last request.

-

When a ZMQ_REP socket enters an exceptional state due to having reached the -high water mark for a client, then any replies sent to the client in -question shall be dropped until the exceptional state ends.

-
Summary of ZMQ_REP characteristics
- - - - - - - - - - - - - - - - - - - - - - - - -
-Compatible peer sockets -
-		 -

-ZMQ_REQ -

-
-Direction -
-		 -

-Bidirectional -

-
-Send/receive pattern -
-		 -

-Receive, Send, Receive, Send, … -

-
-Incoming routing strategy -
-		 -

-Fair-queued -

-
-Outgoing routing stratagy -
-		 -

-Last peer -

-
-ZMQ_HWM option action -
-		 -

-Drop -

-
-

ZMQ_XREQ

-

A socket of type ZMQ_XREQ is an advanced pattern used for extending -request/reply sockets. Each message sent is load-balanced among all connected -peers, and each message received is fair-queued from all connected peers.

-

When a ZMQ_XREQ socket enters an exceptional state due to having reached the -high water mark for all peers, or if there are no peers at all, then any -zmq_send(3) operations on the socket shall block until the exceptional -state ends or at least one peer becomes available for sending; messages are not -discarded.

-

When a ZMQ_XREQ socket is connected to a ZMQ_REP socket each message sent -must consist of an empty message part, the delimiter, followed by one or more -body parts.

-
Summary of ZMQ_XREQ characteristics
- - - - - - - - - - - - - - - - - - - - - - - - -
-Compatible peer sockets -
-		 -

-ZMQ_XREP, ZMQ_REP -

-
-Direction -
-		 -

-Bidirectional -

-
-Send/receive pattern -
-		 -

-Unrestricted -

-
-Outgoing routing strategy -
-		 -

-Load-balanced -

-
-Incoming routing strategy -
-		 -

-Fair-queued -

-
-ZMQ_HWM option action -
-		 -

-Block -

-
-

ZMQ_XREP

-

A socket of type ZMQ_XREP is an advanced pattern used for extending -request/reply sockets. When receiving messages a ZMQ_XREP socket shall -prepend a message part containing the identity of the originating peer to the -message before passing it to the application. Messages received are fair-queued -from among all connected peers. When sending messages a ZMQ_XREP socket shall -remove the first part of the message and use it to determine the identity of -the peer the message shall be routed to.

-

When a ZMQ_XREP socket enters an exceptional state due to having reached the -high water mark for all peers, or if there are no peers at all, then any -messages sent to the socket shall be dropped until the exceptional state ends. -Likewise, any messages routed to a non-existent peer or a peer for which the -individual high water mark has been reached shall also be dropped.

-

When a ZMQ_REQ socket is connected to a ZMQ_XREP socket, in addition to the -identity of the originating peer each message received shall contain an empty -delimiter message part. Hence, the entire structure of each received message -as seen by the application becomes: one or more identity parts, delimiter -part, one or more body parts. When sending replies to a ZMQ_REQ socket the -application must include the delimiter part.

-
Summary of ZMQ_XREP characteristics
- - - - - - - - - - - - - - - - - - - - - - - - -
-Compatible peer sockets -
-		 -

-ZMQ_XREQ, ZMQ_REQ -

-
-Direction -
-		 -

-Bidirectional -

-
-Send/receive pattern -
-		 -

-Unrestricted -

-
-Outgoing routing strategy -
-		 -

-See text -

-
-Incoming routing strategy -
-		 -

-Fair-queued -

-
-ZMQ_HWM option action -
-		 -

-Drop -

-
-

Publish-subscribe pattern

-

The publish-subscribe pattern is used for one-to-many distribution of data from -a single publisher to multiple subscribers in a fanout fashion.

-

ZMQ_PUB

-

A socket of type ZMQ_PUB is used by a publisher to distribute data. -Messages sent are distributed in a fanout fashion to all connected peers. -The zmq_recv(3) function is not implemented for this socket type.

-

When a ZMQ_PUB socket enters an exceptional state due to having reached the -high water mark for a subscriber, then any messages that would be sent to the -subscriber in question shall instead be dropped until the exceptional state -ends.

-
Summary of ZMQ_PUB characteristics
- - - - - - - - - - - - - - - - - - - - - - - - -
-Compatible peer sockets -
-		 -

-ZMQ_SUB -

-
-Direction -
-		 -

-Unidirectional -

-
-Send/receive pattern -
-		 -

-Send only -

-
-Incoming routing strategy -
-		 -

-N/A -

-
-Outgoing routing strategy -
-		 -

-Fanout -

-
-ZMQ_HWM option action -
-		 -

-Drop -

-
-

ZMQ_SUB

-

A socket of type ZMQ_SUB is used by a subscriber to subscribe to data -distributed by a publisher. Initially a ZMQ_SUB socket is not subscribed to -any messages, use the ZMQ_SUBSCRIBE option of zmq_setsockopt(3) to -specify which messages to subscribe to. The zmq_send() function is not -implemented for this socket type.

-
Summary of ZMQ_SUB characteristics
- - - - - - - - - - - - - - - - - - - - - - - - -
-Compatible peer sockets -
-		 -

-ZMQ_PUB -

-
-Direction -
-		 -

-Unidirectional -

-
-Send/receive pattern -
-		 -

-Receive only -

-
-Incoming routing strategy -
-		 -

-Fair-queued -

-
-Outgoing routing strategy -
-		 -

-N/A -

-
-ZMQ_HWM option action -
-		 -

-N/A -

-
-

Pipeline pattern

-

The pipeline pattern is used for distributing data to nodes arranged in -a pipeline. Data always flows down the pipeline, and each stage of the pipeline -is connected to at least one node. When a pipeline stage is connected to -multiple nodes data is load-balanced among all connected nodes.

-

ZMQ_PUSH

-

A socket of type ZMQ_PUSH is used by a pipeline node to send messages -to downstream pipeline nodes. Messages are load-balanced to all connected -downstream nodes. The zmq_recv() function is not implemented for this -socket type.

-

When a ZMQ_PUSH socket enters an exceptional state due to having reached the -high water mark for all downstream nodes, or if there are no downstream -nodes at all, then any zmq_send(3) operations on the socket shall -block until the exceptional state ends or at least one downstream node -becomes available for sending; messages are not discarded.

-

Deprecated alias: ZMQ_DOWNSTREAM.

-
Summary of ZMQ_PUSH characteristics
- - - - - - - - - - - - - - - - - - - - - - - - -
-Compatible peer sockets -
-		 -

-ZMQ_PULL -

-
-Direction -
-		 -

-Unidirectional -

-
-Send/receive pattern -
-		 -

-Send only -

-
-Incoming routing strategy -
-		 -

-N/A -

-
-Outgoing routing strategy -
-		 -

-Load-balanced -

-
-ZMQ_HWM option action -
-		 -

-Block -

-
-

ZMQ_PULL

-

A socket of type ZMQ_PULL is used by a pipeline node to receive messages -from upstream pipeline nodes. Messages are fair-queued from among all -connected upstream nodes. The zmq_send() function is not implemented for -this socket type.

-

Deprecated alias: ZMQ_UPSTREAM.

-
Summary of ZMQ_PULL characteristics
- - - - - - - - - - - - - - - - - - - - - - - - -
-Compatible peer sockets -
-		 -

-ZMQ_PUSH -

-
-Direction -
-		 -

-Unidirectional -

-
-Send/receive pattern -
-		 -

-Receive only -

-
-Incoming routing strategy -
-		 -

-Fair-queued -

-
-Outgoing routing strategy -
-		 -

-N/A -

-
-ZMQ_HWM option action -
-		 -

-N/A -

-
-

Exclusive pair pattern

-

The exclusive pair is an advanced pattern used for communicating exclusively -between two peers.

-

ZMQ_PAIR

-

A socket of type ZMQ_PAIR can only be connected to a single peer at any one -time. No message routing or filtering is performed on messages sent over a -ZMQ_PAIR socket.

-

When a ZMQ_PAIR socket enters an exceptional state due to having reached the -high water mark for the connected peer, or if no peer is connected, then -any zmq_send(3) operations on the socket shall block until the peer -becomes available for sending; messages are not discarded.

-
- - - -
-
Note
-		ZMQ_PAIR sockets are experimental, and are currently missing several -features such as auto-reconnection.
-
-
Summary of ZMQ_PAIR characteristics
- - - - - - - - - - - - - - - - - - - - - - - - -
-Compatible peer sockets -
-		 -

-ZMQ_PAIR -

-
-Direction -
-		 -

-Bidirectional -

-
-Send/receive pattern -
-		 -

-Unrestricted -

-
-Incoming routing strategy -
-		 -

-N/A -

-
-Outgoing routing strategy -
-		 -

-N/A -

-
-ZMQ_HWM option action -
-		 -

-Block -

-
-
-

RETURN VALUE

-
-

The zmq_socket() function shall return an opaque handle to the newly created -socket if successful. Otherwise, it shall return NULL and set errno to one of -the values defined below.

-
-

ERRORS

-
-
-
-EINVAL -
-
-

-The requested socket type is invalid. -

-
-
-EMTHREAD -
-
-

-The maximum number of sockets within this context has been exceeded. -

-
-
-EFAULT -
-
-

-The provided context was not valid (NULL). -

-
-
-
-

SEE ALSO

-
-

zmq_init(3) -zmq_setsockopt(3) -zmq_bind(3) -zmq_connect(3) -zmq_send(3) -zmq_recv(3) -zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_socket.txt b/doc/zmq_socket.txt index 2156af2..6250b38 100644 --- a/doc/zmq_socket.txt +++ b/doc/zmq_socket.txt @@ -35,7 +35,7 @@ sockets transfer streams of bytes or discrete datagrams, 0MQ sockets transfer discrete _messages_. 0MQ sockets being _asynchronous_ means that the timings of the physical -connection setup and teardown, reconnect and effective delivery are transparent +connection setup and tear down, reconnect and effective delivery are transparent to the user and organized by 0MQ itself. Further, messages may be _queued_ in the event that a peer is unavailable to receive them. @@ -46,6 +46,11 @@ relationships. With the exception of 'ZMQ_PAIR', 0MQ sockets may be connected incoming connections *from multiple endpoints* bound to the socket using _zmq_bind()_, thus allowing many-to-many relationships. +.Thread safety +0MQ 'sockets' are _not_ thread safe. Applications MUST NOT use a socket +from multiple threads except after migrating a socket from one thread to +another with a "full fence" memory barrier. + .Socket types The following sections present the socket types defined by 0MQ, grouped by the general _messaging pattern_ which is built from related socket types. @@ -88,7 +93,8 @@ A socket of type 'ZMQ_REP' is used by a _service_ to receive requests from and send replies to a _client_. This socket type allows only an alternating sequence of _zmq_recv(request)_ and subsequent _zmq_send(reply)_ calls. Each request received is fair-queued from among all _clients_, and each reply sent -is routed to the _client_ that issued the last request. +is routed to the _client_ that issued the last request. If the original +requester doesn't exist any more the reply is silently discarded. When a 'ZMQ_REP' socket enters an exceptional state due to having reached the high water mark for a _client_, then any replies sent to the _client_ in @@ -100,29 +106,32 @@ Compatible peer sockets:: 'ZMQ_REQ' Direction:: Bidirectional Send/receive pattern:: Receive, Send, Receive, Send, ... Incoming routing strategy:: Fair-queued -Outgoing routing stratagy:: Last peer +Outgoing routing strategy:: Last peer ZMQ_HWM option action:: Drop -ZMQ_XREQ -^^^^^^^^ -A socket of type 'ZMQ_XREQ' is an advanced pattern used for extending +ZMQ_DEALER +^^^^^^^^^^ +A socket of type 'ZMQ_DEALER' is an advanced pattern used for extending request/reply sockets. Each message sent is load-balanced among all connected peers, and each message received is fair-queued from all connected peers. -When a 'ZMQ_XREQ' socket enters an exceptional state due to having reached the +Previously this socket was called 'ZMQ_XREQ' and that name remains available +for backwards compatibility. + +When a 'ZMQ_DEALER' socket enters an exceptional state due to having reached the high water mark for all peers, or if there are no peers at all, then any linkzmq:zmq_send[3] operations on the socket shall block until the exceptional state ends or at least one peer becomes available for sending; messages are not discarded. -When a 'ZMQ_XREQ' socket is connected to a 'ZMQ_REP' socket each message sent +When a 'ZMQ_DEALER' socket is connected to a 'ZMQ_REP' socket each message sent must consist of an empty message part, the _delimiter_, followed by one or more _body parts_. [horizontal] -.Summary of ZMQ_XREQ characteristics -Compatible peer sockets:: 'ZMQ_XREP', 'ZMQ_REP' +.Summary of ZMQ_DEALER characteristics +Compatible peer sockets:: 'ZMQ_ROUTER', 'ZMQ_REP' Direction:: Bidirectional Send/receive pattern:: Unrestricted Outgoing routing strategy:: Load-balanced @@ -130,23 +139,27 @@ Incoming routing strategy:: Fair-queued ZMQ_HWM option action:: Block -ZMQ_XREP -^^^^^^^^ -A socket of type 'ZMQ_XREP' is an advanced pattern used for extending -request/reply sockets. When receiving messages a 'ZMQ_XREP' socket shall +ZMQ_ROUTER +^^^^^^^^^^ +A socket of type 'ZMQ_ROUTER' is an advanced pattern used for extending +request/reply sockets. When receiving messages a 'ZMQ_ROUTER' socket shall prepend a message part containing the _identity_ of the originating peer to the message before passing it to the application. Messages received are fair-queued -from among all connected peers. When sending messages a 'ZMQ_XREP' socket shall +from among all connected peers. When sending messages a 'ZMQ_ROUTER' socket shall remove the first part of the message and use it to determine the _identity_ of -the peer the message shall be routed to. +the peer the message shall be routed to. If the peer does not exist anymore +the message shall be silently discarded. -When a 'ZMQ_XREP' socket enters an exceptional state due to having reached the +Previously this socket was called 'ZMQ_XREP' and that name remains available +for backwards compatibility. + +When a 'ZMQ_ROUTER' socket enters an exceptional state due to having reached the high water mark for all peers, or if there are no peers at all, then any messages sent to the socket shall be dropped until the exceptional state ends. Likewise, any messages routed to a non-existent peer or a peer for which the individual high water mark has been reached shall also be dropped. -When a 'ZMQ_REQ' socket is connected to a 'ZMQ_XREP' socket, in addition to the +When a 'ZMQ_REQ' socket is connected to a 'ZMQ_ROUTER' socket, in addition to the _identity_ of the originating peer each message received shall contain an empty _delimiter_ message part. Hence, the entire structure of each received message as seen by the application becomes: one or more _identity_ parts, _delimiter_ @@ -154,8 +167,8 @@ part, one or more _body parts_. When sending replies to a 'ZMQ_REQ' socket the application must include the _delimiter_ part. [horizontal] -.Summary of ZMQ_XREP characteristics -Compatible peer sockets:: 'ZMQ_XREQ', 'ZMQ_REQ' +.Summary of ZMQ_ROUTER characteristics +Compatible peer sockets:: 'ZMQ_DEALER', 'ZMQ_REQ' Direction:: Bidirectional Send/receive pattern:: Unrestricted Outgoing routing strategy:: See text @@ -166,19 +179,19 @@ ZMQ_HWM option action:: Drop Publish-subscribe pattern ~~~~~~~~~~~~~~~~~~~~~~~~~ The publish-subscribe pattern is used for one-to-many distribution of data from -a single _publisher_ to multiple _subscribers_ in a fanout fashion. +a single _publisher_ to multiple _subscribers_ in a fan out fashion. ZMQ_PUB ^^^^^^^ A socket of type 'ZMQ_PUB' is used by a _publisher_ to distribute data. -Messages sent are distributed in a fanout fashion to all connected peers. +Messages sent are distributed in a fan out fashion to all connected peers. The linkzmq:zmq_recv[3] function is not implemented for this socket type. When a 'ZMQ_PUB' socket enters an exceptional state due to having reached the high water mark for a _subscriber_, then any messages that would be sent to the _subscriber_ in question shall instead be dropped until the exceptional state -ends. +ends. The _zmq_send()_ function shall never block for this socket type. [horizontal] .Summary of ZMQ_PUB characteristics @@ -186,7 +199,7 @@ Compatible peer sockets:: 'ZMQ_SUB' Direction:: Unidirectional Send/receive pattern:: Send only Incoming routing strategy:: N/A -Outgoing routing strategy:: Fanout +Outgoing routing strategy:: Fan out ZMQ_HWM option action:: Drop @@ -205,7 +218,7 @@ Direction:: Unidirectional Send/receive pattern:: Receive only Incoming routing strategy:: Fair-queued Outgoing routing strategy:: N/A -ZMQ_HWM option action:: N/A +ZMQ_HWM option action:: Drop Pipeline pattern @@ -262,8 +275,9 @@ ZMQ_HWM option action:: N/A Exclusive pair pattern ~~~~~~~~~~~~~~~~~~~~~~ -The exclusive pair is an advanced pattern used for communicating exclusively -between two peers. +The exclusive pair pattern is used to connect a peer to precisely one other +peer. This pattern is used for inter-thread communication across the inproc +transport. ZMQ_PAIR @@ -277,8 +291,10 @@ high water mark for the connected peer, or if no peer is connected, then any linkzmq:zmq_send[3] operations on the socket shall block until the peer becomes available for sending; messages are not discarded. -NOTE: 'ZMQ_PAIR' sockets are experimental, and are currently missing several -features such as auto-reconnection. +NOTE: 'ZMQ_PAIR' sockets are designed for inter-thread communication across +the linkzmq:zmq_inproc[7] transport and do not implement functionality such +as auto-reconnection. 'ZMQ_PAIR' sockets are considered experimental and may +have other missing or broken aspects. [horizontal] .Summary of ZMQ_PAIR characteristics @@ -301,11 +317,10 @@ ERRORS ------ *EINVAL*:: The requested socket 'type' is invalid. -*EMTHREAD*:: -The maximum number of sockets within this 'context' has been exceeded. *EFAULT*:: The provided 'context' was not valid (NULL). - +*ETERM*:: +The context specified was terminated. SEE ALSO -------- @@ -315,10 +330,11 @@ linkzmq:zmq_bind[3] linkzmq:zmq_connect[3] linkzmq:zmq_send[3] linkzmq:zmq_recv[3] +linkzmq:zmq_inproc[7] linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_streamer.1 b/doc/zmq_streamer.1 deleted file mode 100644 index 2537be7..0000000 --- a/doc/zmq_streamer.1 +++ /dev/null @@ -1,57 +0,0 @@ -'\" t -.\" Title: zmq_streamer -.\" Author: [see the "AUTHORS" section] -.\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 -.\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 -.\" Language: English -.\" -.TH "ZMQ_STREAMER" "1" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" -.\" ----------------------------------------------------------------- -.\" * Define some portability stuff -.\" ----------------------------------------------------------------- -.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.\" http://bugs.debian.org/507673 -.\" http://lists.gnu.org/archive/html/groff/2009-02/msg00013.html -.\" ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -.ie \n(.g .ds Aq \(aq -.el .ds Aq ' -.\" ----------------------------------------------------------------- -.\" * set default formatting -.\" ----------------------------------------------------------------- -.\" disable hyphenation -.nh -.\" disable justification (adjust text to left margin only) -.ad l -.\" ----------------------------------------------------------------- -.\" * MAIN CONTENT STARTS HERE * -.\" ----------------------------------------------------------------- -.SH "NAME" -zmq_streamer \- streamer device for parallelized pipeline messaging -.SH "SYNOPSIS" -.sp -To be written\&. -.SH "DESCRIPTION" -.sp -To be written\&. -.SH "OPTIONS" -.sp -To be written\&. -.SH "SEE ALSO" -.sp -\fBzmq\fR(7) -.SH "AUTHORS" -.sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. -.SH "NOTES" -.IP " 1." 4 -sustrik@250bpm.com -.RS 4 -\%mailto:sustrik@250bpm.com -.RE -.IP " 2." 4 -mato@kotelna.sk -.RS 4 -\%mailto:mato@kotelna.sk -.RE diff --git a/doc/zmq_streamer.html b/doc/zmq_streamer.html deleted file mode 100644 index 038ef97..0000000 --- a/doc/zmq_streamer.html +++ /dev/null @@ -1,613 +0,0 @@ - - - - - -zmq_streamer(1) - - - - - -
-

SYNOPSIS

-
-

To be written.

-
-

DESCRIPTION

-
-

To be written.

-
-

OPTIONS

-
-

To be written.

-
-

SEE ALSO

-
-

zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_streamer.txt b/doc/zmq_streamer.txt deleted file mode 100644 index c8d517b..0000000 --- a/doc/zmq_streamer.txt +++ /dev/null @@ -1,33 +0,0 @@ -zmq_streamer(1) -=============== - - -NAME ----- -zmq_streamer - streamer device for parallelized pipeline messaging - - -SYNOPSIS --------- -To be written. - - -DESCRIPTION ------------ -To be written. - - -OPTIONS -------- -To be written. - - -SEE ALSO --------- -linkzmq:zmq[7] - - -AUTHORS -------- -The 0MQ documentation was written by Martin Sustrik and -Martin Lucina . diff --git a/doc/zmq_strerror.3 b/doc/zmq_strerror.3 index ab9507a..43bb42e 100644 --- a/doc/zmq_strerror.3 +++ b/doc/zmq_strerror.3 @@ -2,12 +2,12 @@ .\" Title: zmq_strerror .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_STRERROR" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_STRERROR" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -64,7 +64,7 @@ if (!ctx) { \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_strerror.html b/doc/zmq_strerror.html deleted file mode 100644 index 4cc4faf..0000000 --- a/doc/zmq_strerror.html +++ /dev/null @@ -1,634 +0,0 @@ - - - - - -zmq_strerror(3) - - - - - -
-

SYNOPSIS

-
-

const char *zmq_strerror (int errnum);

-
-

DESCRIPTION

-
-

The zmq_strerror() function shall return a pointer to an error message string -corresponding to the error number specified by the errnum argument. As ØMQ -defines additional error numbers over and above those defined by the operating -system, applications should use zmq_strerror() in preference to the standard -strerror() function.

-
-

RETURN VALUE

-
-

The zmq_strerror() function shall return a pointer to an error message -string.

-
-

ERRORS

-
-

No errors are defined.

-
-

EXAMPLE

-
-
-
Displaying an error message when a ØMQ context cannot be initialised
-
-
void *ctx = zmq_init (1, 1, 0);
-if (!ctx) {
-    printf ("Error occurred during zmq_init(): %s\n", zmq_strerror (errno));
-    abort ();
-}
-
-
-

SEE ALSO

-
-

zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_strerror.txt b/doc/zmq_strerror.txt index 61f30e3..2cd9829 100644 --- a/doc/zmq_strerror.txt +++ b/doc/zmq_strerror.txt @@ -51,5 +51,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_tcp.7 b/doc/zmq_tcp.7 index 75c7949..08fba12 100644 --- a/doc/zmq_tcp.7 +++ b/doc/zmq_tcp.7 @@ -2,12 +2,12 @@ .\" Title: zmq_tcp .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_TCP" "7" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_TCP" "7" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -49,7 +49,7 @@ An \fIinterface\fR may be specified by either of the following: .sp -1 .IP \(bu 2.3 .\} -The wildcard +The wild\-card *, meaning all available interfaces\&. .RE .sp @@ -197,10 +197,10 @@ The following diagram illustrates the layout of a frame with a \fIpayload length /* TCP port 5555 on all available interfaces */ rc = zmq_bind(socket, "tcp://*:5555"); assert (rc == 0); -/* TCP port 5555 on the local loopback interface on all platforms */ +/* TCP port 5555 on the local loop\-back interface on all platforms */ rc = zmq_bind(socket, "tcp://127\&.0\&.0\&.1:5555"); assert (rc == 0); -/* TCP port 5555 on the first ethernet network interface on Linux */ +/* TCP port 5555 on the first Ethernet network interface on Linux */ rc = zmq_bind(socket, "tcp://eth0:5555"); assert (rc == 0); .fi @@ -230,7 +230,7 @@ assert (rc == 0); \fBzmq_bind\fR(3) \fBzmq_connect\fR(3) \fBzmq_pgm\fR(7) \fBzmq_ipc\fR(7) \fBzmq_inproc\fR(7) \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_tcp.html b/doc/zmq_tcp.html deleted file mode 100644 index 99a5897..0000000 --- a/doc/zmq_tcp.html +++ /dev/null @@ -1,755 +0,0 @@ - - - - - -zmq_tcp(7) - - - - - -
-

SYNOPSIS

-
-

TCP is an ubiquitous, reliable, unicast transport. When connecting distributed -applications over a network with ØMQ, using the TCP transport will likely be -your first choice.

-
-

ADDRESSING

-
-

A ØMQ address string consists of two parts as follows: -transport://endpoint. The transport part specifies the underlying -transport protocol to use, and for the TCP transport shall be set to tcp. -The meaning of the endpoint part for the TCP transport is defined below.

-

Assigning a local address to a socket

-

When assigning a local address to a socket using zmq_bind() with the tcp -transport, the endpoint shall be interpreted as an interface followed by a -colon and the TCP port number to use.

-

An interface may be specified by either of the following:

-
    -
  • -

    -The wildcard *, meaning all available interfaces. -

    -
    • -
  • -

    -The primary IPv4 address assigned to the interface, in its numeric - representation. -

    -
    • -
  • -

    -The interface name as defined by the operating system. -

    -
    • -
-
- - - -
-
Note
-		Interface names are not standardised in any way and should be assumed to -be arbitrary and platform dependent. On Win32 platforms no short interface -names exist, thus only the primary IPv4 address may be used to specify an -interface.
-
-

Connecting a socket

-

When connecting a socket to a peer address using zmq_connect() with the tcp -transport, the endpoint shall be interpreted as a peer address followed by -a colon and the TCP port number to use.

-

A peer address may be specified by either of the following:

-
    -
  • -

    -The DNS name of the peer. -

    -
    • -
  • -

    -The IPv4 address of the peer, in it’s numeric representation. -

    -
    • -
-
-

WIRE FORMAT

-
-

ØMQ messages are transmitted over TCP in frames consisting of an encoded -payload length, followed by a flags field and the message body. The payload -length is defined as the combined length in octets of the message body and the -flags field.

-

For frames with a payload length not exceeding 254 octets, the payload -length shall be encoded as a single octet. The minimum valid payload length -of a frame is 1 octet, thus a payload length of 0 octets is invalid and such -frames SHOULD be ignored.

-

For frames with a payload length exceeding 254 octets, the payload length -shall be encoded as a single octet with the value 255 followed by the -payload length represented as a 64-bit unsigned integer in network byte -order.

-

The flags field consists of a single octet containing various control flags:

-

Bit 0 (MORE): More message parts to follow. A value of 0 indicates that there -are no more message parts to follow; or that the message being sent is not a -multi-part message. A value of 1 indicates that the message being sent is a -multi-part message and more message parts are to follow.

-

Bits 1-7: Reserved. Bits 1-7 are reserved for future expansion and MUST be -set to zero.

-

The following ABNF grammar represents a single frame:

-
-
-
    frame           = (length flags data)
-    length          = OCTET / (escape 8OCTET)
-    flags           = OCTET
-    escape          = %xFF
-    data            = *OCTET
-
-

The following diagram illustrates the layout of a frame with a payload length -not exceeding 254 octets:

-
-
-
0                   1                   2                   3
-0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Payload length|     Flags     |       Message body        ... |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Message body ...
-+-+-+-+-+-+-+- ...
-
-

The following diagram illustrates the layout of a frame with a payload length -exceeding 254 octets:

-
-
-
0                   1                   2                   3
-0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|     0xff      |               Payload length              ... |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|                       Payload length                      ... |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-| Payload length|     Flags     |        Message body       ... |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-|  Message body ...
-+-+-+-+-+-+-+-+ ...
-
-
-

EXAMPLES

-
-
-
Assigning a local address to a socket
-
-
/* TCP port 5555 on all available interfaces */
-rc = zmq_bind(socket, "tcp://*:5555");
-assert (rc == 0);
-/* TCP port 5555 on the local loopback interface on all platforms */
-rc = zmq_bind(socket, "tcp://127.0.0.1:5555");
-assert (rc == 0);
-/* TCP port 5555 on the first ethernet network interface on Linux */
-rc = zmq_bind(socket, "tcp://eth0:5555");
-assert (rc == 0);
-
-
-
Connecting a socket
-
-
/* Connecting using an IP address */
-rc = zmq_connect(socket, "tcp://192.168.1.1:5555");
-assert (rc == 0);
-/* Connecting using a DNS name */
-rc = zmq_connect(socket, "tcp://server1:5555");
-assert (rc == 0);
-
-
-

SEE ALSO

-
-

zmq_bind(3) -zmq_connect(3) -zmq_pgm(7) -zmq_ipc(7) -zmq_inproc(7) -zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_tcp.txt b/doc/zmq_tcp.txt index 29fa181..a0c945a 100644 --- a/doc/zmq_tcp.txt +++ b/doc/zmq_tcp.txt @@ -30,7 +30,7 @@ colon and the TCP port number to use. An 'interface' may be specified by either of the following: -* The wildcard `*`, meaning all available interfaces. +* The wild-card `*`, meaning all available interfaces. * The primary IPv4 address assigned to the interface, in its numeric representation. * The interface name as defined by the operating system. @@ -127,10 +127,10 @@ EXAMPLES /* TCP port 5555 on all available interfaces */ rc = zmq_bind(socket, "tcp://*:5555"); assert (rc == 0); -/* TCP port 5555 on the local loopback interface on all platforms */ +/* TCP port 5555 on the local loop-back interface on all platforms */ rc = zmq_bind(socket, "tcp://127.0.0.1:5555"); assert (rc == 0); -/* TCP port 5555 on the first ethernet network interface on Linux */ +/* TCP port 5555 on the first Ethernet network interface on Linux */ rc = zmq_bind(socket, "tcp://eth0:5555"); assert (rc == 0); ---- @@ -158,5 +158,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_term.3 b/doc/zmq_term.3 index 0f6daa4..608df99 100644 --- a/doc/zmq_term.3 +++ b/doc/zmq_term.3 @@ -2,12 +2,12 @@ .\" Title: zmq_term .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_TERM" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_TERM" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -34,37 +34,39 @@ zmq_term \- terminate 0MQ context \fBint zmq_term (void \fR\fB\fI*context\fR\fR\fB);\fR .SH "DESCRIPTION" .sp -The \fIzmq_term()\fR function terminates the 0MQ context \fIcontext\fR\&. +The \fIzmq_term()\fR function shall terminate the 0MQ context \fIcontext\fR\&. .sp -If there are no longer any sockets open within \fIcontext\fR at the time \fIzmq_term()\fR is called then \fIcontext\fR shall be shut down and all associated resources shall be released immediately\&. -.sp -Otherwise, the following applies: +Context termination is performed in the following steps: .sp .RS 4 .ie n \{\ -\h'-04'\(bu\h'+03'\c +\h'-04' 1.\h'+01'\c .\} .el \{\ .sp -1 -.IP \(bu 2.3 +.IP " 1." 4.2 .\} -The -\fIzmq_term()\fR -function shall return immediately\&. +Any blocking operations currently in progress on sockets open within +\fIcontext\fR +shall return immediately with an error code of ETERM\&. With the exception of +\fIzmq_close()\fR, any further operations on sockets open within +\fIcontext\fR +shall fail with an error code of ETERM\&. .RE .sp .RS 4 .ie n \{\ -\h'-04'\(bu\h'+03'\c +\h'-04' 2.\h'+01'\c .\} .el \{\ .sp -1 -.IP \(bu 2.3 +.IP " 2." 4.2 .\} -Any blocking operations currently in progress on sockets open within -\fIcontext\fR -shall return immediately with an error code of ETERM\&. -.RE +After interrupting all blocking calls, +\fIzmq_term()\fR +shall +\fIblock\fR +until the following conditions are satisfied: .sp .RS 4 .ie n \{\ @@ -74,10 +76,10 @@ shall return immediately with an error code of ETERM\&. .sp -1 .IP \(bu 2.3 .\} -With the exception of -\fIzmq_close()\fR, any further operations on sockets open within +All sockets open within \fIcontext\fR -shall fail with an error code of ETERM\&. +have been closed with +\fIzmq_close()\fR\&. .RE .sp .RS 4 @@ -88,12 +90,16 @@ shall fail with an error code of ETERM\&. .sp -1 .IP \(bu 2.3 .\} -The actual shutdown of -\fIcontext\fR, and release of any associated resources, -\fBshall be delayed\fR -until the last socket within it is closed with -\fIzmq_close()\fR\&. +For each socket within +\fIcontext\fR, all messages sent by the application with +\fIzmq_send()\fR +have either been physically transferred to a network peer, or the socket\(cqs linger period set with the +\fIZMQ_LINGER\fR +socket option has expired\&. +.RE .RE +.sp +For further details regarding socket linger behaviour refer to the \fIZMQ_LINGER\fR option in \fBzmq_setsockopt\fR(3)\&. .SH "RETURN VALUE" .sp The \fIzmq_term()\fR function shall return zero if successful\&. Otherwise it shall return \-1 and set \fIerrno\fR to one of the values defined below\&. @@ -105,12 +111,17 @@ The provided \fIcontext\fR was not valid (NULL)\&. .RE +.PP +\fBEINTR\fR +.RS 4 +Termination was interrupted by a signal\&. It can be restarted if needed\&. +.RE .SH "SEE ALSO" .sp -\fBzmq\fR(7) \fBzmq_init\fR(3) +\fBzmq\fR(7) \fBzmq_init\fR(3) \fBzmq_close\fR(3) \fBzmq_setsockopt\fR(3) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_term.html b/doc/zmq_term.html deleted file mode 100644 index 54af0d7..0000000 --- a/doc/zmq_term.html +++ /dev/null @@ -1,658 +0,0 @@ - - - - - -zmq_term(3) - - - - - -
-

SYNOPSIS

-
-

int zmq_term (void *context);

-
-

DESCRIPTION

-
-

The zmq_term() function terminates the ØMQ context context.

-

If there are no longer any sockets open within context at the time -zmq_term() is called then context shall be shut down and all associated -resources shall be released immediately.

-

Otherwise, the following applies:

-
    -
  • -

    -The zmq_term() function shall return immediately. -

    -
    • -
  • -

    -Any blocking operations currently in progress on sockets open within - context shall return immediately with an error code of ETERM. -

    -
    • -
  • -

    -With the exception of zmq_close(), any further operations on sockets open - within context shall fail with an error code of ETERM. -

    -
    • -
  • -

    -The actual shutdown of context, and release of any associated resources, - shall be delayed until the last socket within it is closed with - zmq_close(). -

    -
    • -
-
-

RETURN VALUE

-
-

The zmq_term() function shall return zero if successful. Otherwise it shall -return -1 and set errno to one of the values defined below.

-
-

ERRORS

-
-
-
-EFAULT -
-
-

-The provided context was not valid (NULL). -

-
-
-
-

SEE ALSO

-
-

zmq(7) -zmq_init(3)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_term.txt b/doc/zmq_term.txt index f3ffa01..c7e13d7 100644 --- a/doc/zmq_term.txt +++ b/doc/zmq_term.txt @@ -14,25 +14,27 @@ SYNOPSIS DESCRIPTION ----------- -The _zmq_term()_ function terminates the 0MQ context 'context'. +The _zmq_term()_ function shall terminate the 0MQ context 'context'. -If there are no longer any sockets open within 'context' at the time -_zmq_term()_ is called then 'context' shall be shut down and all associated -resources shall be released immediately. +Context termination is performed in the following steps: -Otherwise, the following applies: +1. Any blocking operations currently in progress on sockets open within + 'context' shall return immediately with an error code of ETERM. With the + exception of _zmq_close()_, any further operations on sockets open within + 'context' shall fail with an error code of ETERM. -* The _zmq_term()_ function shall return immediately. +2. After interrupting all blocking calls, _zmq_term()_ shall _block_ until the + following conditions are satisfied: ++ + * All sockets open within 'context' have been closed with _zmq_close()_. -* Any blocking operations currently in progress on sockets open within - 'context' shall return immediately with an error code of ETERM. + * For each socket within 'context', all messages sent by the application + with _zmq_send()_ have either been physically transferred to a network + peer, or the socket's linger period set with the _ZMQ_LINGER_ socket + option has expired. -* With the exception of _zmq_close()_, any further operations on sockets open - within 'context' shall fail with an error code of ETERM. - -* The actual shutdown of 'context', and release of any associated resources, - *shall be delayed* until the last socket within it is closed with - _zmq_close()_. +For further details regarding socket linger behaviour refer to the _ZMQ_LINGER_ +option in linkzmq:zmq_setsockopt[3]. RETURN VALUE @@ -45,15 +47,19 @@ ERRORS ------ *EFAULT*:: The provided 'context' was not valid (NULL). +*EINTR*:: +Termination was interrupted by a signal. It can be restarted if needed. SEE ALSO -------- linkzmq:zmq[7] linkzmq:zmq_init[3] +linkzmq:zmq_close[3] +linkzmq:zmq_setsockopt[3] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . diff --git a/doc/zmq_version.3 b/doc/zmq_version.3 index a53df35..36248e5 100644 --- a/doc/zmq_version.3 +++ b/doc/zmq_version.3 @@ -2,12 +2,12 @@ .\" Title: zmq_version .\" Author: [see the "AUTHORS" section] .\" Generator: DocBook XSL Stylesheets v1.75.2 -.\" Date: 10/15/2010 +.\" Date: 03/15/2011 .\" Manual: 0MQ Manual -.\" Source: 0MQ 2.0.10 +.\" Source: 0MQ 2.1.3 .\" Language: English .\" -.TH "ZMQ_VERSION" "3" "10/15/2010" "0MQ 2\&.0\&.10" "0MQ Manual" +.TH "ZMQ_VERSION" "3" "03/15/2011" "0MQ 2\&.1\&.3" "0MQ Manual" .\" ----------------------------------------------------------------- .\" * Define some portability stuff .\" ----------------------------------------------------------------- @@ -34,7 +34,7 @@ zmq_version \- report 0MQ library version \fBvoid zmq_version (int \fR\fB\fI*major\fR\fR\fB, int \fR\fB\fI*minor\fR\fR\fB, int \fR\fB\fI*patch\fR\fR\fB);\fR .SH "DESCRIPTION" .sp -The \fIzmq_version()\fR function shall fill in the integer variables pointed to by the \fImajor\fR, \fIminor\fR and \fIpatch\fR arguments with the major, minor and patchlevel components of the 0MQ library version\&. +The \fIzmq_version()\fR function shall fill in the integer variables pointed to by the \fImajor\fR, \fIminor\fR and \fIpatch\fR arguments with the major, minor and patch level components of the 0MQ library version\&. .sp This functionality is intended for applications or language bindings dynamically linking to the 0MQ library that wish to determine the actual version of the 0MQ library they are using\&. .SH "RETURN VALUE" @@ -64,7 +64,7 @@ printf ("Current 0MQ version is %d\&.%d\&.%d\en", major, minor, patch); \fBzmq\fR(7) .SH "AUTHORS" .sp -The 0MQ documentation was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. +This 0MQ manual page was written by Martin Sustrik <\m[blue]\fBsustrik@250bpm\&.com\fR\m[]\&\s-2\u[1]\d\s+2> and Martin Lucina <\m[blue]\fBmato@kotelna\&.sk\fR\m[]\&\s-2\u[2]\d\s+2>\&. .SH "NOTES" .IP " 1." 4 sustrik@250bpm.com diff --git a/doc/zmq_version.html b/doc/zmq_version.html deleted file mode 100644 index 841a7d2..0000000 --- a/doc/zmq_version.html +++ /dev/null @@ -1,632 +0,0 @@ - - - - - -zmq_version(3) - - - - - -
-

SYNOPSIS

-
-

void zmq_version (int *major, int *minor, int *patch);

-
-

DESCRIPTION

-
-

The zmq_version() function shall fill in the integer variables pointed to by -the major, minor and patch arguments with the major, minor and patchlevel -components of the ØMQ library version.

-

This functionality is intended for applications or language bindings -dynamically linking to the ØMQ library that wish to determine the actual -version of the ØMQ library they are using.

-
-

RETURN VALUE

-
-

There is no return value.

-
-

ERRORS

-
-

No errors are defined.

-
-

EXAMPLE

-
-
-
Printing out the version of the ØMQ library
-
-
int major, minor, patch;
-zmq_version (&major, &minor, &patch);
-printf ("Current 0MQ version is %d.%d.%d\n", major, minor, patch);
-
-
-

SEE ALSO

-
-

zmq(7)

-
-

AUTHORS

-
-

The ØMQ documentation was written by Martin Sustrik <sustrik@250bpm.com> and -Martin Lucina <mato@kotelna.sk>.

-
-
-
- - - diff --git a/doc/zmq_version.txt b/doc/zmq_version.txt index 0ad3a55..eeb0b40 100644 --- a/doc/zmq_version.txt +++ b/doc/zmq_version.txt @@ -15,7 +15,7 @@ SYNOPSIS DESCRIPTION ----------- The _zmq_version()_ function shall fill in the integer variables pointed to by -the 'major', 'minor' and 'patch' arguments with the major, minor and patchlevel +the 'major', 'minor' and 'patch' arguments with the major, minor and patch level components of the 0MQ library version. This functionality is intended for applications or language bindings @@ -49,5 +49,5 @@ linkzmq:zmq[7] AUTHORS ------- -The 0MQ documentation was written by Martin Sustrik and +This 0MQ manual page was written by Martin Sustrik and Martin Lucina . -- cgit v1.2.3