This reverts commit b6c577a9.

Using 'ipc://@abstract-socket' on non-Linux platforms yields inconsistent
behaviour.  Abstract sockets don't exist, so the literal file is created.
The test previously failed, but for a different reason: this is not the
directory you are looking for.  Now, zmq_bind() will fail for the right
reason: the socket can't be created.  Put the XFAIL back.

fork() support is optional and its availability is correctly detected at
contfigure time.

But test_fork was all always built, preventing build for targets that do
not provide fork() from building successfully.

This pacth fixes the autotools on this point.

- also prioritize ZAP metadata over ZMTP metadata in case application
  uses same names.

Few examples:
tcp:://192.168.0.4:55555;192.168.0.254:1234
tcp:://192.168.0.4:0;192.168.0.254:1234
tcp:://eth2:55555;192.168.0.254:1234

- this failing test was confusing users
- ZMTP v3.0 now does not define resources at all
- resources, along with other unimplemented aspects moved to
  RFC 37 ZMTP v3.1

This reverts commit bc7441f5.

- renamed test_stream_disconnect_notifications (too long!)
- removed print statements in that test case
- fixed Makefile.am for test_zap_ipc_creds (was not building)

When a ZMQ_STREAM socket connection is broken (intentionally, via `shutdown()`
or accidentally via client crash or network failure), there is no way for the
application to dertermine that it should drop per-connection data (such as
buffers).

This contribution makes sure the application receives a 0-length message to
notify it that the connection has been broken.  This is symmetric with the
process of closing the connection from within the application (where the
application sends a 0-length message to tell ZeroMQ to close the connection).

Conflicts:
	CMakeLists.txt

Also moved the fd field from message content to message itself

- This seems redundant; is there a use case for NOT providing
  the IPC credentials to the ZAP authenticator?

- More, why is IPC authentication done via libzmq instead of ZAP?
  Is it because we're missing the transport type on the ZAP request?

Another take on LIBZMQ-568 to allow filtering IPC connections, this time
using ZAP.  This change is backward compatible.  If the
ZMQ_ZAP_IPC_CREDS option is set, the user, group, and process IDs of the
peer process are appended to the address (separated by colons) of a ZAP
request; otherwise, nothing changes.  See LIBZMQ-568 and zmq_setsockopt
documentation for more information.

Adds ZMQ_IPC_ACCEPT_FILTER_{PID,UID,GID} socket options to add processs,
user, and group IDs to the IPC filter sets. Fixes LIBZMQ-568.

See https://github.com/zeromq/issues/pull/7Signed-off-by: Shannen Saez <shannenlaptop@gmail.com>

As TIPC transport for 0MQ will only work on post 3.8
Linux kernels where nonblocking connect was added,
we add AC_RUN test to check for this functionality.
Should the test fail, tipc is excluded from build/test.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>

The tests are identical to the TCP ones, only the
addressing is changed.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>

Shorten ZMQ_ROUTER_REASSIGN_IDENTITIES to ZMQ_ROUTER_HANDOVER. Also, added a test for the HANDOVER functionality.

* The ZMQ_ROUTER_RAW API was deprecated in favor of ZMQ_STREAM
* Same issue hit router.cpp, which I've fixed

See issue 567.

* Tests dealer-to-router connection 100 times
* This was failing in ZMQ v4.0.0 RC1

* ZMQ_REQ_STRICT was negative option (default 1) which goes against
  the standard, where defaults are zero. I renamed this to
  ZMQ_REQ_RELAXED.

* ZMQ_REQ_REQUEST_IDS felt clumsy and describes the technical solution
  rather than the problem/requirement. I changed to ZMQ_REQ_CORRELATE
  which seems more explicit.

* The ZMQ_CONNECT_DELAY option was renamed to ZMQ_IMMEDIATE