op / go-nanomsg Goto Github PK

Normal implementations support @ symbol in ipc, for exmaple: "ipc://@/tmp/blah.ipc"

That means abstract unix pipe. go-nanomsg crashes with that. Abstract sockets, the C-way: "ipc://\x00/tmp/blah.ipc" kindof work - but the /tmp/blah.ipc is ignored and it's treated as abstract socket without a name: "@"

I have this weird error. errno is 34 which doesn't make sense. I tested with an older version of nanomsg but I still have the problem. I'm wondering if I got this since I upgrader to go 1.1.2.

The last time I edited nanomsg and use printf to show errno, it wasn't 34 even if I got it when calling C.nn_socket.

I'm going to try with go 1.1.1.

I'm on windows/amd64.

C:\dev\go-nanomsg>go test
--- FAIL: TestError (0.01 seconds)
        error_test.go:15: Le lecteur ne contient pas la bonne disquette.
                Insérez %2 (numéro de série de volume : %3) dans le lecteur %1.
FAIL
exit status 1
FAIL    _/C_/dev/go-nanomsg     0.171s

I build nanomsg using VC 2012 express and I use mingw64 with Go. Could this be the source of my problem?

The is currently no way to read or set headers on raw sockets.

We are delivering nanomsg 0.9 and later with nanomsg.pc as the file.

The closed bool on Socket isn't protected by a mutex so if Close is called multiple times from different goroutines at the same time the blocking operation http://nanomsg.org/v0.0.0/nn_close.3.html can be invoked multiple times simultaneously.

https://github.com/op/go-nanomsg/blob/master/nanomsg.go#L53

It looks calling nn_close on a closed socket only ever results in a return of EBADF indicating the socket was already closed so I don't see much point in the check to begin with (or, to go on a tangent, why that's an error in this case because it's kind of like saying "error: already done" and what's the point? I wanted to close the socket and the socket's closed: personally I'd check if the error is EBADF and if so return nil) unless it is to add threadsafety in which case every nn_whatever call should be protected by a single mutex and the closed flag is still of dubious import.

Hello,

When nanomsg timeouts happen in succession I regulary see this assertion. Unable to figure out what exactly is going on here. I do not explicitly close the socket (except cycle it every 5 mins). Is the nanomsg socket destroyed on a timeout?

I'll try to find a code snippet to reproduce this issue. Platform is Linux Ubuntu 15.04

Log of the assertion:-
/usr/local/lib/libnanomsg.so.5.0.0(+0x1c090)[0x7f5d4fe7a090]
/usr/local/lib/libnanomsg.so.5.0.0(nn_chunk_free+0x18)[0x7f5d4fe79e68]
/usr/local/lib/libnanomsg.so.5.0.0(nn_chunkref_term+0x2f)[0x7f5d4fe7a25e]
/usr/local/lib/libnanomsg.so.5.0.0(nn_msg_term+0x38)[0x7f5d4fe7bb0f]
/usr/local/lib/libnanomsg.so.5.0.0(nn_req_term+0x42)[0x7f5d4fe82bae]
/usr/local/lib/libnanomsg.so.5.0.0(nn_req_destroy+0x20)[0x7f5d4fe82c2a]
/usr/local/lib/libnanomsg.so.5.0.0(+0x15486)[0x7f5d4fe73486]
/usr/local/lib/libnanomsg.so.5.0.0(nn_fsm_feed+0x5c)[0x7f5d4fe749c7]
/usr/local/lib/libnanomsg.so.5.0.0(nn_fsm_event_process+0x67)[0x7f5d4fe74968]
/usr/local/lib/libnanomsg.so.5.0.0(nn_ctx_leave+0x5c)[0x7f5d4fe7470b]
/usr/local/lib/libnanomsg.so.5.0.0(+0x1ba37)[0x7f5d4fe79a37]
/usr/local/lib/libnanomsg.so.5.0.0(+0x1e9b6)[0x7f5d4fe7c9b6]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x76aa)[0x7f5d4fc476aa]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f5d4f97d13d]
Assertion failed: nn_getl ((uint8_t*) p - sizeof (uint32_t)) == NN_CHUNK_TAG (/tmp/nanomsg-1.0.0/src/utils/chunk.c:211)

See: fanin and fanout protocols merged into a single pipeline protocol nanomsg/nanomsg@4cea0a0

Simple SUB code leaks memory

    sub1, err := nanomsg.NewSubSocket()
    if err != nil {
        fmt.Fprintf(os.Stderr, "[!] nanomsg.NewSubSocket() %v\n", err.Error())
        os.Exit(3)
    }

    if err = sub1.Subscribe(""); err != nil {
        fmt.Fprintf(os.Stderr, "[!] nanomsg.Subscribe() %v\n", err.Error())
        os.Exit(3)
    }

    if _, err = sub1.Connect(url); err != nil {
        fmt.Fprintf(os.Stderr, "[!] nanomsg.Connect(%v) %v\n", url, err.Error())
        os.Exit(3)
    }

    for {
        payload, err := sub1.Recv(0)
        if err != nil {
            fmt.Fprintf(os.Stderr, "[!] nanomsg.Recv(): %s\n", err.Error())
            os.Exit(3)
        }
        }

Is it possible to have a pair of functions that send and receive strings?

Something like: (haven't tried compiling)

func (*soc Socket) recvString(flags int, size int64) string {
b, err := soc.Recv()
length, err := soc.RecvBuffer()
s := string(b[:length])
}

func (*soc Socket) sendString(s String, flags int) (int, error) {
...
}

Hello,
I am using mq-benchmarking (https://github.com/tylertreat/mq-benchmarking/blob/master/benchmark/mq/nanomsg.go) to test the latency for nanomsg.

e.g
./mq-benchmarking nanomsg true 50000 256

It is dropping the messages. I did try to increase the send and receive buffer size but it doesn't helps upto certain extent.

If you use my modified version of mq-benchmarking project (https://github.com/rohitjoshi/mq-benchmarking) which has more logging, you can see messages are dropped.

./bin/mq-benchmarking  nanomsg  true 50000 256
2014/11/02 19:48:42 mq-benchmarking subject=nanomsg test-latency=true  msg-count=50000  msg-size=256
2014/11/02 19:48:42 Begin nanomsg test
2014/11/02 19:48:42 Setup is invoked
2014/11/02 19:48:45 TestLatency:Sending 50000 message...
2014/11/02 19:48:45 Sent 50000 messages in 97.141968 ms
2014/11/02 19:48:45 Sent 514710.593750 per second
2014/11/02 19:48:45 Receiver started
2014/11/02 19:48:45 Mean latency for 50000 messages: 73.490311 ms
2014/11/02 19:48:45 Latency: Max=97.206200 ms,  Min=56.200539 ms,
2014/11/02 19:48:45 Number of messages above mean latency: 19895
2014/11/02 19:48:45 Number of messages below mean latency: 19517
2014/11/02 19:48:45 Number of messages with mean latency: 0
2014/11/02 19:48:45 End nanomsg test

Here if you see, total messages received are 19895 + 19517 = 39412. It should have received 50,000 messages.

Do you know how can this be solved?

I have experienced message corruption when using go-nanomsg in my application. The issue is very rare (e.g., 1 in 10^7 messages).

Messages were corrupted in one of two ways: (a) message was shortened by a few bytes, or (b) message was preceded and succeeded by junk data.

Corruption definitely occurred on the receive size: it can be stopped by setting zeroCopy := false in nanomsg.go#L163, and other subscribers to the same publisher got the correct message. The issue occurred for both pub/sub and push/pull sockets.

In the absence of a simple proof of concept, I will provide a few details about my application at the time of observing this bug. It is a high-bandwidth research prototype, sending and receiving lots of small messages (e.g. 10-100 bytes, up to 500k msg/s per node). Each node maintains one pub socket and one pull socket. Every node connects a sub and push to every other node. The pull socket and all the sub sockets are read in a closed loop, with one goroutine for each socket and without any locking. I make a copy of the received data right after Recv returns. Go version used was go1.4rc1 linux/amd64.

It would be nice to be able to build and install go-nanomsg using static linking. I choose nanomsg over zmq because it was written in pure C, and is thus easily linkable in a single Go binary.

In my fork I changed the link flags to use static linking which worked perfectly:

// #include <nanomsg/nn.h>
// #include <stdlib.h>
-// #cgo LDFLAGS: -lnanomsg
+// #cgo CFLAGS: -I/usr/local/include/nanomsg
+// #cgo LDFLAGS: /usr/local/lib/libnanomsg.a
 import "C"

Is there a way to have this as an option when using "go get github.com/op/go-nanomsg"? It would be even cleaner if that command in addition could also clone a local copy of nanomsg and build it for only the static linking, letting the users completely ignore the C library.

It seems the version format changed in nanomsg/nanomsg@0a5ccfd

go build
# github.com/op/go-nanomsg
1: error: 'NN_VERSION_MAJOR' undeclared (first use in this function)
1: note: each undeclared identifier is reported only once for each function it appears in
1: error: 'NN_VERSION_MINOR' undeclared (first use in this function)
1: error: 'NN_VERSION_PATCH' undeclared (first use in this function)

I see the following log line occasionally on our backend - "Assertion failed: type == NN_USOCK_ERROR (../deps/nanomsg/src/transports/utils/streamhdr.c:264)". Things still continue to work though.

Could someone please shed light on why this could be happening so I can track down what I am doing wrong and fix it.

Regards.
Deepak.

I've been trying to install this using go get, but I keep running into this error.

$ go get github.com/op/go-nanomsg
B:\src\hcg\src\github.com\op\go-nanomsg\bus.go:5:26: fatal error: nanomsg/bus.h: No such file or directory
// #include <nanomsg/bus.h>

Any ideas? I assume that you need to point it to nanomsg/src somehow, but I can't seem to figure that out.