[nanomsg] Re: Questions
- From: Paul Colomiets <paul@xxxxxxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Mon, 24 Mar 2014 23:47:31 +0200
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)
--
Paul
Other related posts:
