Hi Laurent,
On Mon, Mar 24, 2014 at 1:43 PM, Laurent Alebarde <l.alebarde@xxxxxxx> wrote:
Hi all,
I am studying the documentation of nanomsg and have a few questions please:
nn_setsockopt
NN_SNDBUF: I don't understand this sentense: "To prevent blocking for
messages larger than the buffer, exactly one message may be buffered in
addition to the data in the send buffer.". What happens if I try to send a
message that exceeds the size of this buffer ?
It just works. The SNDBUF influences only the memory/throughput ratio.
I.e. it's optimization and it's expected that OS usually guesses good
enough value. It's also directly corresponds for SO_SNDBUF, so you can
google for good practices of customizing it. The only nuance is that
NN_SNDBUF sets the buffer size for each connection.
If a message is already waiting in the buffer and another one is sent, does
the send return an error, what is the behaviour ?
nn_send
If message doesn't fit buffer, it's tail (the part that doesn't fit)
is stored in the memory, and until that piece fully fits the buffer,
there are two cases:
1. For PUB, BUS and REP sockets nn_send discards the message and returns success
2. For PUSH, REQ and PAIR sockets nn_send returns EAGAIN (or waits
for NN_SNDTIMEO)
(I don't remember exactly for survey, I can lookup if you care)
For confirmation: either we are in blocking mode, then the socket tries to
send the message for NN_SNDTIMEO ms and returns EAGAIN if it cannot, either
we are in non-blocking mode, and it returns also EAGAIN if it cannot succeed
immediately ?
There is no "blocking mode" of socket. But I believe you mean
NN_DONTWAIT flag. See above.
"Any bytes exceeding the length specified by the len argument will be
truncated." : are the bytes truncated lost, or will be fetched in the next
receive command ?
It gets lost. Similarly to how UDP works. Actually you are expected to
use NN_MSG in the most common scenario where you don't know message
size.
nn_cmsg
NN_CMSG_SPACE and NN_CMSG_LEN not understood.
Never used, sorry.
nn_poll
"Note - nn_poll is a convenience function. You can achieve same behaviour by
using NN_RCVFD and NN_SNDFD socket options.": NN_RCVFD and NN_SNDFD are not
documented in nn_setsockopt.
They are documented in nn_getsockopt, you aren't going to set them. Only read.
nn_env : page error
Yeah. You can check out git version and build manual pages there. They
are ok. Eventually site will be updated.
nn_pair:
what happens if I try to bind several end-points to such a socket ? Is errno
EMFILE issued ?
You can bind any number, as long as only single connection is established.
nn_reqrep
Is the retry inhibited if NN_REQ_RESEND_IVL is set to 0 ?
It seems not. I.e. it probably a but that zero and negative intervals
are not checked for. Also, Martin, it seems insane to retry the
request by default. I would be very surpized of request repeat after a
60 seconds. And I don't think there is one size fits all default
interval.
nn_pubsub
What is the criteria for an incoming message to trigger the subscription ?
The first bytes shall fit the subscription string ?
Yes.
nn_ipc
In both cases, Windows or POSIX, one uses ipc://xxx in is code, and it is
translated to
ipc://xxx in POSIX box and \\.\pipe\xxx in Windows ?
IIRC, the IPC for Windows doesn't work yet. But intention is right.
(Except I'm not competent to say that \\.\pipe\xxx is a right path)
