ZMQ_CLIENT send not blocking

[Cross22]

Issue description

Invoking zmq_send() with a ZMQ_CLIENT socket which is NOT connected to a peer causes the message to be queued. Once a peer connects the queued message gets sent. This is in contrast to the documentation which states that send should be blocking when there is no peer.

Sample code

void *context = zmq_ctx_new ();
void *sock = zmq_socket (context, ZMQ_CLIENT);
zmq_connect (sock, "tcp://127.0.0.1:12345");
zmq_send(sock, "HELLO", 6, 0);
printf("Why am I here when no data was sent?");

Environment

• libzmq version (commit hash if unreleased): 4.2.5
• OS: OSX

What's the actual result? (include assertion message & call stack if applicable)

Function call returns indicating number of bytes sent.

What's the expected result?

Function blocks until it is able to send the data.

[trya]

This behavior can also be encountered with ZMQ_DEALER, ZMQ_REQ and ZMQ_PUSH sockets (all sockets that are supposed to block when connected to no peer). Apparently, the culprit is the socket_base_t::connect method:

libzmq/src/socket_base.cpp

Lines 949 to 963 in 2cb1240

	if (options.immediate != 1 || subscribe_to_all) {
	// Create a bi-directional pipe.
	object_t *parents[2] = {this, session};
	pipe_t *new_pipes[2] = {NULL, NULL};
	const bool conflate = get_effective_conflate_option (options);
	int hwms[2] = {conflate ? -1 : options.sndhwm,
	conflate ? -1 : options.rcvhwm};
	bool conflates[2] = {conflate, conflate};
	rc = pipepair (parents, new_pipes, hwms, conflates);
	errno_assert (rc == 0);
	// Attach local end of the pipe to the socket object.
	attach_pipe (new_pipes[0], subscribe_to_all, true);

If the ZMQ_IMMEDIATE option is not set, a pipe is forcibly attached to the socket, thus making the socket accepting messages in its sending queue even when it's not connected to a peer. Setting ZMQ_IMMEDIATE to true will restore the expected behavior when send is called. I don't know if the documentation should change to reflect the new behavior or if ZMQ_IMMEDIATE set to true should be the default for these socket types.

[bluca]

Behaviour of sockets cannot be changed (apart from the client one as it's still draft), so it's the documentation that needs updating. Feel free to send a PR.

[trya]

As per RFCs 28/REQREP and 30/PIPELINE:

For processing outgoing messages:

• SHALL block on sending, or return a suitable error, when it has no connected peers.

As of now, the documentation sticks with the RFCs, but libzmq sockets do not comply. Are you really sure that updating the documentation is the right course of action?

[bluca]

Yes - it's mostly an internal detail with no consequences for networked peers, and changing it is a breackage of backward compatibility

[sigiesec]

@bluca Do you imply that the statement should be removed from the RFC?

[bluca]

It can be left there, there's no reason for other implementations to change it, it has no effect on the protocol

[stale]

This issue has been automatically marked as stale because it has not had activity for 365 days. It will be closed if no further activity occurs within 56 days. Thank you for your contributions.