This change simply provides the user with a socket option that sets a user defined name of the next outbound connection:
zmq_setsockopt(routerSock,ZMQ_NEXT_IDENTITY,"myname",6);
if(0 > zmq_connect(routerSock,"tcp://127.0.0.1:1234")) return 1;
ret = zmq_send(routerSock,"myname",6,ZMQ_SNDMORE);
zmq_send(routerSock,b.mem,b.used,0);
In this example, the socket is immediately given the name "myname", and is capable of immediately sending traffic.
This approach is more effective in three ways:
1) It prevents all sorts of malicious peer naming attacks that can cause undefined behavior in existing ROUTER connections. (Two connections are made that both transmit the same name to the ROUTER, the ROUTER behavior is undefined)
2) It allows immediate control of connections made to external parties for STREAM sockets. Something that is not possible right now. Before an outbound connection had no name for STREAM or ROUTER sockets because outbound connections cannot be sent to without first receiving traffic.
3) It is simpler and more general than expecting two ROUTER sockets to handshake on assigned connection names. Plus it allows inline sending to new connections on ROUTER.
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
The get_credential () member function returns
credential for the last peer we received message for.
The idea is that this function is used to implement user-level API.
This reverts commit f27eb67e1abb0484c41050e454404cce30647b63, reversing
changes made to a3ae0d4c16c892a4e6c96d626a7c8b7068450336.
https://zeromq.jira.com/browse/LIBZMQ-576
Conflicts:
src/stream_engine.cpp
Conflicts were around additional defaults to the constructor after the
'terminating' default. The additional defaults were left alone, and
the 'terminating' default was removed.
- 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 sets of process (Linux only), user, and group IDs for filtering
connections from peer processes over IPC transport. If all of the
filter sets are empty, every connection is accepted. Otherwise,
credentials for a connecting process are checked against the filter sets
and the connection is only accepted if a match is found.
This commit is part of LIBZMQ-568 and only adds the filter sets and
implements the filter in the IPC accept method. The interface for
adding IDs to filter sets are included in a separate commit.
IPC accept filtering is supported only on Linux and OS X.
By default, TIPC uses a closest first approach to find
a publication that can satisfy your connection request.
Any publication on the local node will automatically
be chosen for all requests, even if you're trying to
spread it out over multiple machines.
We fix this by widening the default lookup scope.
Signed-off-by: Erik Hugne <erik.hugne@ericsson.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>
A ZeroMQ application can opt for TIPC based sockets
using the TIPC port name format:
zmq_bind(sb, "tipc://{type,lower,upper}");
zmq_connect(sc, "tipc://{type,inst}");
'type' is the service ID, and 'lower/upper' can be
used for service partitioning or basic load
balancing.
ZeroMQ TIPC transport requires a kernel >= 3.8
(nonblocking connect support for TIPC).
Signed-off-by: Erik Hugne <erik.hugne@ericsson.com>
- removed unnecessary malloc
- spaces, not tabs to indent
- renamed control states to be more logical
- renamed SUSPEND to PAUSE, feels more accurate
- fixed indentation, which was off in places
Abstract socket pathnames must have a NULL character in the first
position, but the second character must also be checked to differentiate
an abstract name from the empty string. The address length must also
indicate the length of the pathname because the kernel uses the entire
address as the name, including NULL characters. ZMQ uses
NULL-terminated strings for the address, so the abstract address length
is the length of the string following the initial NULL byte plus 3; two
bytes for the address family and one for the initial NULL character.
Converts an initial strudel or "at sign" (@) in the Unix socket path to
a NULL character ('\0') indicating that the socket uses the abstract
namespace instead of the filesystem namespace. For instance, binding a
socket to 'ipc://@/tmp/tester' will not create a file associated with
the socket whereas binding to 'ipc:///tmp/tester' will create the file
/tmp/tester. See issue 567 for more information.
