This is supposed to become part of the ZMTP/1.1.
The main differences from the ZMTP/1.0 framing protocol are:
- flags field comes first, followed by the length field
- long messages are signaled using a flag rather then 0xff escape
- length field does not include the flags field, 0 is a valid value
Hopefully fixed LIBZMQ-427 - there was a slight typo in the init_address
refactor. The encoder refactoring had also broken pgm_sender and
receiver, but just required updating to use the new functions.
Since ZMQ 2.x does not support subscription forwarding, it's not
possible to use ZMQ 2.x SUB socket to receive messages from a PUB
socket.
This patch adds some compatibility layer so that ZMQ 2.x SUB socket
receives messages from PUB socket.
The new protocol adds support for protocol version and exchanges the
socket type, so that the library can reject a connection when the
sockets do not match.
The protocol was designed so that it's possible to detect and fully
support ZTP/1.0 peers.
When a new connection is set up, peers exchange greeting messages. The
greeting message encodes both the protocol verion and the socket type.
The format of the greeting message is as follows:
greeting = tag1, adaptation, tag2, version, length, socket_type
tag1 = BYTE / 0xff
adaptation = 8 BYTES
tag2 = BYTE / 0x7f
version = BYTE / 1
length = BYTE / 1
socket_type = BYTE
The protocol does not define the value of adaptation field.
When interoperability with ZTP/1.0 peers is required, the adaptaion
encodes, in network byte order, the length of identity message increased
by 1. When adaptaion consists of eight zeros, the current
implementatatio of 0MQ 2.x closes the connection.
This patch supports both ZTP/1.0 and new protocol.
This formerly unused parameter actually represents the socket
on which the event was received. As such, we should check that
its value makes sense: it must be either "rep" or "req", and in
the case of some kinds of events, it must be specifically one
or the other.
After this change, "s" is no longer unused.
Compiling without warnings is a good goal, because it makes
new warnings (which probably indicate bugs) stand out rather
than getting lost in the spam.
My fixes fall into two categories:
- Adding (void) casts of unused parameters, where their
unusedness seems like a TODO (or in some cases a bug?).
- Removing parameter names altogether, where the function
is clearly a stub that will never use its parameters.
Should be no change in behavior.
char_traits<unsigned char>::to_char_type(x) used to return 0 no matter
what x was, and likewise to_int_type(x) used to return 0 no matter what.
(0 is what you get when you default-construct an integral type, which
is what the old code was doing.) This seemed like buggy behavior to me,
so I've changed it.
Code as stands breaks shutdown process. It was a bugfix by Arthur to a
bad line which was testing for an impossible state - but afaics we do
actually want to flush in those states. It is possible I am wrong on
that though - if there are any shutdown issues introduced aroudn this
commit I would suggest further investigation around this flushing
behavior.
There are three versions of monitor_event(), all taking
variadic arguments. The original code just has the first one
creating a va_list and passing that va_list variadically to
the second one... which creates a new va_list and passes it
variadically to the third one... and of course everything
blows up when we try to pull a non-va_list argument off the
stack.
The correct approach matches the C standard library's use
of printf/vprintf, scanf/vscanf, and so on. Once you make
a va_list, you must pass it only to functions which expect
a va_list parameter.
Static analysis says:
src\tcp_address.cpp(297): error V595: The 'res' pointer was utilized before it was verified against nullptr. Check lines: 297, 301.
src\tcp_address.cpp(603): error V106: Implicit type conversion third argument 'full_bytes' of function 'memcmp' to memsize type.
src\tcp_address.cpp(603): error V526: The 'memcmp' function returns 0 if corresponding buffers are equal. Consider examining the condition for mistakes.
In fact the use of "memcmp" is correct, but the enclosing "if" isn't
necessary, and the compiler is happier if "full_bytes" is a size_t.
Static analysis says:
src\pipe.cpp(193): error V547: Expression is always false. Probably the '||' operator should be used here.
If flush() is called on a pipe whose state was
"terminated" or "double_terminated", the programmer's
intent was to return immediately. But in fact the
two conditions can never be true simultaneously, so
the early return never happens, and we may try to flush
a terminated pipe anyway.
Static analysis says:
src\zmq.cpp(489): error V220: Suspicious sequence of types castings: memsize -> 32-bit integer -> memsize. The value being casted: '* count_'.
src\zmq.cpp(510): error V127: An overflow of the 32-bit 'nread' variable is possible inside a long cycle which utilizes a memsize-type loop counter.
I've silenced the warning on line 489 and ignored the other.
But also, it looks to me like there's a serious bug here: The
out-parameter "count_" is never set to zero before we start
incrementing it. So its final value will always be between
1 and 2 times its initial value. The fix seems obvious.
Both memcmp and strcmp return zero on equal, nonzero on nonequal;
so all of these tests were backwards.
The original committer fixed the failure by comparing 22 bytes instead
of the correct 21, so that the assertions would trigger only if the
22nd byte happened to match exactly --- which was rare.
The correct fix is to compare the right number of bytes with the
right sense. (I think all of the ".addr" fields are null-terminated,
in which case it's more appropriate to use strcmp throughout.)
Notice that ZeroMQ has never been compiled for Thumb2 before,
and I personally don't make any guarantees that it will actually
behave correctly once compiled. But after this patch, it is at
least *possible* to compile it for Thumb2.
(Thumb2 is the target for most iOS devices.)
Revert zmq_poll NULL poll items check to 2.2 behavior - let the poll items count filter out empty poll sets and not return a sometimes unexpected EFAULT error status
When a peer reconnects, the router socket receives an identity
message containing this peer id. When this happens, the current
implementation crashes.
This patch makes a router socket to silently ignore all identity
messages coming from reconnected peers.
By assigning a SECURITY_DESCRIPTOR to the event we gain the ability to
share it between service and console programs. We also added
EVENT_MODIFY_STATE as a requirement to OpenEvent so we can SetEvent later
in the method.
When closing an ipc listener, the library may try to unlink
the associated file. When this fails, the underlying
socket is not marked as retired and this triggers
assertion failure.
Fixes issue #397
This also fixes a bug in tcp_connecter and tcp_listener, which
generated the event not when they failed to close the socket but
when the succeed to close it.
avoids warnings of the form:
warning: 'struct iovec' declared inside parameter list
warning: its scope is only this definition or declaration, which is probably not what you want
when building downstream projects
The patch is meant to make the code easier to understand.
The 'wait' attribute is replaced by 'delayed_start'
and 'timer_started' attributes. The former is constant and
is initialized in the constructor. The latter is a flag
reflecting whether a timer has been started and changes during
the lifetime of the object.
- Android crosscompiler shows a warning about two signed/unsigned checks
on compilation, this patch adds casts to avoid this, so zmq3.x can
compile on it.
