Cleaning up recent option names #1786
Conversation
Solution: rename to ZMQ_MAXRT This is the option name used on Windows, so easier to use and remember.
This option has a few issues. The name is long and clumsy. The functonality is not smooth: one must set both this and ZMQ_XPUB_VERBOSE at the same time, or things will break mysteriously. Solution: rename to ZMQ_XPUB_VERBOSER and make an atomic option. That is, implicitly does ZMQ_XPUB_VERBOSE.
The proper name is ZMQ_THREAD_SAFE Solution: fix in the documentation.
These options are confusing and redundant. Their names suggest they apply to the tcp:// transport, yet they are used for all stream protocols. The methods zmq::set_tcp_receive_buffer and zmq::set_tcp_send_buffer don't use these values at all, they use ZMQ_SNDBUF and ZMQ_RCVBUF. Solution: merge these new options into ZMQ_SNDBUF and ZMQ_RCVBUF. This means defaulting these two options to 8192, and removing the new options. We now have ZMQ_SNDBUF and ZMQ_RCVBUF being used both for TCP socket control, and for input/output buffering. Note: the default for SNDBUF and RCVBUF are otherwise 4096.
And I'm on a reasonably sized laptop. I think allocating INT_MAX memory is dangerous in a test case. Solution: expose this as a context option. I've used ZMQ_MAX_MSGSZ and documented it and implemented the API. However I don't know how to get the parent context for a socket, so the code in zmq.cpp is still unfinished.
|
This defines (but does not implement) a "maximum" max msg size as INT_MAX. Shouldn't that be closer to SIZE_MAX, instead? This seems strange to me, because larger messages do work, providing |
|
OK, so this change is unfinished. The Why do you think it would never work? |
INT_MAX seems a fine default, but the docs added here state that it's not just the default, it's also the max allowed value:
I read that as:
Therefore:
Is that wrong? Are you only meaning to set the truncation for |
|
You're right, the code isn't correct. I misread it. So I want to change the problem statement to "unlimited message size is an insecure default." In that case a realistic max size is indeed SIZE_MAX. I need someone to help me access the parent context from a socket_base and then I can finish this... Thanks for the explanations. |
|
I noticed that there is already a ZMQ_MAXMSGSIZE socket option, which is applied to receiving messages. Perhaps that should be extended to sends, rather than adding a new context option. |
|
Good catch. This is a socket option, whereas I'd started making a context OK, I'll scratch my patch and look at using the socket ZMQ_MAXMSGSIZE. On Thu, Feb 11, 2016 at 11:21 AM, Min RK notifications@github.com wrote:
|
@minrk I've also noticed the large message test freezes my laptop for a few seconds. Since we're now implementing a maximum message size, I've made this configurable via zmq_ctx_set(). This was long overdue I think. Needs a little help to be fully working.