* Problem: Still need to port over more files to VxWorks 6.x
Solution: Port more files to VxWorks 6.x
* Problem: Need to port over remaining files to VxWorks 6.x. Also remove POSIX thread dependency for VxWorks (because of priority inversion problem in POSIX mutexes with VxWorks 6.x processes)
Solution: Port over remaining files to VxWorks 6.x. Also removed POSIX thread dependency for VxWorks
* Problem: Needed to modify TCP, UDP, TIPC classes with #ifdefs to be compatible with VxWorks 6.x.
Solution: Modify TCP, UDP, TIPC classes with #ifdefs to be compatible with VxWorks 6.x
Solution: when a connection breaks and ZMQ_RECONNECT_IVL is set to -1,
which means a reconnection will not be attempted, send a message from
the I/O thread to the application thread to make the socket call
term_endpoint, which is the equivalent of manually calling
zmq_disconnect.
This way subsequent zmq_connect call to the same endpoint will attempt
again to do a connection.
Otherwise, for some socket types like SUBs, those new connects will
fail as the endpoint is recorded, despite the connection having been
permanently closed.
Add test cases to exercise this corner case with TCP and IPC.
* Problem: missing test for status code 300, inadequate assertion for status code 500
Solution: add test, change assertion (currently test fails)
* Problem: gcc compiler error deprecated conversion from string constant
Solution: declare variable as const
* Problem: in case of ZAP handler returning a status code other than 200, no appropriate event is emitted
Solution: immediately emit event after receiving reply from ZAP handler
* Problem: endpoint address is not included in zap-reply monitor event
Solution: added functions to retrieve endpoint address in zmq::i_engine and zmq::session_base_t
removed unused code block in zmq::stream_engine_t::next_handshake_command
* Problem: wrong formatting
Solution: fix formatting
* Problem: test fails because of EPIPE
Solution: add EPIPE/ECONNRESET/ECONNAGAIN handling for more test cases
Solution: if a CURVE server is using zmq_connect, the same session
will be used for any client "reconnect" (actual binds). This is
acceptable, so do not assert if zap_pipe already exists during the
handshake, but simply reuse it.
Fixes#2608
Solution: if inproc://zeromq.zap.01 exists, which means ZAP is
enabled, abort immediately if it cannot be used (eg: out of memory)
or it is configured incorrectly (eg: wrong socket type).
Otherwise authentication failures will simply be ignored and
unauthorised peers will be allowed to slip in.
problem: for zmq radio/dish pattern, if the radio process restarts, the dish will not resend subscriptions to radio. And the result is that the dish will never receive any more messages.
solution: in session_base_t::reconnect (), take ZMQ_DISH into consideration when invoking hiccup method.
In function session_base_t::reconnect, if we set immediate to 1 and set linger, we will get into first block of reconnect function, and set pipe to NULL, but we forget to cancel timer of linger. Once timer tiggered, we will get coredump. Solution: cancel timer in the end of set pipe to NULL
- removed the previously added encryption_error, less changes less bug
- handshake fail is now signaled when an error happen while the
mechanism is still hanshaking
Added two new monitoring events:
- ZMQ_EVENT_HANDSHAKE_SUCCEED is raised once the encryption handshake succeed
- ZMQ_EVENT_HANDSHAKE_FAILED is raised when it failed
Both events are raised on server and client side.
VMCI transport allows fast communication between the Host
and a virtual machine, between virtual machines on the same host,
and within a virtual machine (like IPC).
It requires VMware to be installed on the host and Guest Additions
to be installed on a guest.
While sending very large messages (far beyond what fits in a the tcp
buffer, so it takes multiple sendto system calls for it to finish),
zmq_close will close the connection regardless of ZMQ_LINGER.
In case no engine is attached, a pipe->check_read() is needed to look
for the delimiter in the pipe and ultimately trigger the pipe
termination.
However, if there *is* an engine attached, the check_read() looks ahead
and finds the delimiter and terminates the connection even though the
engine might actually still be in the middle of sending a message.
This happens because while the io_thread is still busy sending the data,
the pipe can get terminated and the io thread ends up being terminated.
Of course people still "can" distributed the sources under the
LGPLv3. However we provide COPYING.LESSER with additional grants.
Solution: specify these grants in the header of each source file.
Symptom is that ZMQ_STREAM sockets in 4.1.0 and 4.1.1 generate zero
sized messages on each new connection, unlike 4.0.x which did not do
this.
Person who made this commit also changed test cases so that contract
breakage did not show. Same person was later banned for persistently
poor form in CZMQ contributions.
Solution: enable connect notifications on ZMQ_STREAM sockets using a
new ZMQ_STREAM_NOTIFY setting. By default, socket does not deliver
notifications, and behaves as in 4.0.x.
Fixes#1316
This is still raw and experimental.
To connect through a SOCKS proxy, set ZMQ_SOCKS_PROXY socket option on
socket before issuing a connect call, e.g.:
zmq_setsockopt (s, ZMQ_SOCKS_PROXY,
"127.0.0.1:22222", strlen ("127.0.0.1:22222"));
zmq_connect (s, "tcp://127.0.0.1:5555");
Known limitations:
- only SOCKS version 5 supported
- authentication not supported
- new option is still undocumented
