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