zeromq / goczmq Goto Github PK

View Code? Open in Web Editor NEW

578.0 578.0 91.0 988 KB

goczmq is a golang wrapper for CZMQ.

License: Mozilla Public License 2.0

Makefile 0.32% Go 99.68%

goczmq's People

Contributors

Stargazers

Watchers

Forkers

indradhanush supershabam krattai luna-duclos phenixsh michaelcoyote vrecan looksgood vonwenm jordansissel jouq mengzhuo nbargnesi roger2000 roger2000hk skaar jimjibone mattkanwisher askskype cyrilleverrier patrick-park hodgesds dlpc codelotus containerz systemstart ming-hai curtiszimmerman gocuntian kokizzu kenkao bluca liyonglion sideshowdave7 devopsmi hongjie7202 skyformat99 lydy ashcrow novahe dxfeng10 alvarlaigna beaquant johnnyduo bendikro liminxufen jshlbrd pevecyan shanba xxks-kkk go-zeromq bobertlo putao520 bear-metal deepaksirone wuli133144 renaissanxe bitshiftza p4l1ly timkrentz bluceyee felixstarship mrrogerhuang ec06cumt bombayplayinc keegan-y kyungminkook res-web3 ns-hnguyen lacit shassard joeedt uppercaveman ziyht leedstyh shnitzelil rizalgowandy mutinifni chuanyi-zjc donggiggedin saberboy isgasho mooyang-code melojustme isabella232 vihoyau ns-jenyuanh devo-ody dmoscicki

goczmq's Issues

Add support for ZMQ_SERVER / ZMQ_CLIENT

ZMQ_CLIENT / ZMQ_SERVER support was added to CZMQ ( see: zeromq/czmq#1059 ).

I need to add support for these new socket types to GoCZMQ. It should be done in a way that doesn't break GoCZMQ when built against older versions of CZMQ without these types.

Possible Issue w/ latest ZeroMQ and CZMQ Release Candidates

brian,

i am using czmq-3.0.0-rc1 and zeromq-4.1.0.-rc1

the result of a make build is

find . -name *.go -type f -exec gofmt -w {} ;
go get -t -v ./...
go test -v .
=== RUN TestAuthIPAllow
I: 15-01-17 17:20:09 zauth: API command=ALLOW
I: 15-01-17 17:20:09 zauth: - whitelisting ipaddress=127.0.0.1
I: 15-01-17 17:20:09 zauth: ZAP request mechanism=NULL ipaddress=127.0.0.1
I: 15-01-17 17:20:09 zauth: - passed (whitelist) address=127.0.0.1
I: 15-01-17 17:20:09 zauth: - ZAP reply status_code=200 status_text=OK
I: 15-01-17 17:20:09 zauth: API command=$TERM
--- PASS: TestAuthIPAllow (0.00s)
=== RUN TestAuthPlain
I: 15-01-17 17:20:09 zauth: API command=ALLOW
I: 15-01-17 17:20:09 zauth: - whitelisting ipaddress=127.0.0.1
I: 15-01-17 17:20:09 zauth: API command=PLAIN
I: 15-01-17 17:20:09 zauth: ZAP request mechanism=PLAIN ipaddress=127.0.0.1
I: 15-01-17 17:20:09 zauth: - passed (whitelist) address=127.0.0.1
I: 15-01-17 17:20:09 zauth: - allowed (PLAIN) username=admin password=Password
I: 15-01-17 17:20:09 zauth: - ZAP reply status_code=200 status_text=OK
I: 15-01-17 17:20:09 zauth: ZAP request mechanism=PLAIN ipaddress=127.0.0.1
I: 15-01-17 17:20:09 zauth: - passed (whitelist) address=127.0.0.1
I: 15-01-17 17:20:09 zauth: - denied (PLAIN) username=admin password=BadPassword
I: 15-01-17 17:20:09 zauth: - ZAP reply status_code=400 status_text=No access
I: 15-01-17 17:20:09 zauth: API command=$TERM
--- PASS: TestAuthPlain (0.20s)
=== RUN TestAuthCurveAllow
goczmq.test: src/zsockopt.c:482: zsocket_set_curve_secretkey_bin: Assertion `rc == 0 || zmq_errno () == (156384712 + 53)' failed.
SIGABRT: abort
PC=0x7f0ce5ba2877
signal arrived during cgo execution

goroutine 7 [syscall, locked to thread]:
runtime.cgocall_errno(0x406070, 0xc20801d628, 0x0)
/usr/local/go/src/runtime/cgocall.go:130 +0xf5 fp=0xc20801d608 sp=0xc20801d5e0
github.com/zeromq/goczmq._Cfunc_zsocket_set_curve_secretkey_bin(0x7f0cd800ac90, 0x7f0cd800d010)
github.com/zeromq/goczmq/_test/_obj_test/_cgo_gotypes.go:883 +0x45 fp=0xc20801d628 sp=0xc20801d608
github.com/zeromq/goczmq.(*Cert).Apply(0xc20802c088, 0xc20803c540)
/home/andrew/go/src/github.com/zeromq/goczmq/cert.go:75 +0x5e fp=0xc20801d648 sp=0xc20801d628
github.com/zeromq/goczmq.TestAuthCurveAllow(0xc208056120)
/home/andrew/go/src/github.com/zeromq/goczmq/auth_test.go:211 +0x210 fp=0xc20801d778 sp=0xc20801d648
testing.tRunner(0xc208056120, 0x84e550)
/usr/local/go/src/testing/testing.go:447 +0xbf fp=0xc20801d7d0 sp=0xc20801d778
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:2232 +0x1 fp=0xc20801d7d8 sp=0xc20801d7d0
created by testing.RunTests
/usr/local/go/src/testing/testing.go:555 +0xa8b

goroutine 1 [chan receive]:
testing.RunTests(0x5d1ed8, 0x84e520, 0x40, 0x40, 0x7b05f8fffe641201)
/usr/local/go/src/testing/testing.go:556 +0xad6
testing.(*M).Run(0xc20802e0a0, 0x868fc0)
/usr/local/go/src/testing/testing.go:485 +0x6c
main.main()
github.com/zeromq/goczmq/_test/_testmain.go:178 +0x1d5

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:2232 +0x1

rax 0x0
rbx 0x7f0ce6831000
rcx 0xffffffffffffffff
rdx 0x6
rdi 0x5be7
rsi 0x5be9
rbp 0x7f0ce5ce8b48
rsp 0x7f0ce493dc28
r8 0x1
r9 0xfefefefefeff092d
r10 0x8
r11 0x206
r12 0x7f0ce640df40
r13 0x7f0ce6418760
r14 0x2
r15 0xc20803c360
rip 0x7f0ce5ba2877
rflags 0x206
cs 0x33
fs 0x0
gs 0x0
exit status 2
FAIL github.com/zeromq/goczmq 0.212s
make: *** [test] Error 1

is that enough info for you?

Build failes on FreeBSD 10.1

Hi,
I got this error while building on FreeBSD 10.1:

# github.com/zeromq/goczmq
cc: warning: argument unused during compilation: '-pthread'
# github.com/zeromq/goczmq
src/github.com/zeromq/goczmq/sock.go:267: cannot use unsafe.Pointer(s.zsockT) (type unsafe.Pointer) as type *C.struct__zsock_t in argument to _Cfunc_Sock_sendframe
src/github.com/zeromq/goczmq/sock.go:269: cannot use unsafe.Pointer(s.zsockT) (type unsafe.Pointer) as type *C.struct__zsock_t in argument to _Cfunc_Sock_sendframe
bin build failed

And here is environment info:

# pkg info czmq
czmq-3.0.2_1
Name           : czmq
Version        : 3.0.2_1
Installed on   : Wed Sep 28 20:33:17 2016 EEST
Origin         : net/czmq
Architecture   : freebsd:10:x86:64
Prefix         : /usr/local
Categories     : net
Licenses       : MPL
Maintainer     : [email protected]
WWW            : http://czmq.zeromq.org
Comment        : High-level C Binding for ZeroMQ
Shared Libs required:
    libzmq.so.5
Shared Libs provided:
    libczmq.so.3
Annotations    :
    repo_type      : binary
    repository     : FreeBSD
Flat size      : 1.70MiB
Description    :
High-level C bindings for ZeroMQ.

WWW: http://czmq.zeromq.org

# pkg info libsodium
libsodium-1.0.10
Name           : libsodium
Version        : 1.0.10
Installed on   : Wed Sep 28 20:33:17 2016 EEST
Origin         : security/libsodium
Architecture   : freebsd:10:x86:64
Prefix         : /usr/local
Categories     : security
Licenses       : ISCL
Maintainer     : [email protected]
WWW            : https://github.com/jedisct1/libsodium
Comment        : Library to build higher-level cryptographic tools
Options        :
    DOCS           : on
Shared Libs provided:
    libsodium.so.18
Annotations    :
    repo_type      : binary
    repository     : FreeBSD
Flat size      : 1.36MiB
Description    :
libsodium is a library for network communication, encryption,
decryption, signatures, etc.

libsodium is a portable, cross-compilable, installable,
packageable, API-compatible version of NaCl(security/nacl).
NaCl's goal is to provide all of the core operations needed
to build higher-level cryptographic tools.

WWW: https://github.com/jedisct1/libsodium

Combining Attach on the bind side with a Connect on the connect side fails over inproc on Dealer/Pair sockets

As per title, I have not tested other socket combinations or non inproc

Problem: int64 socket options not yet supported

Currently, int64 options in sockopts.xml are not supported.

Need goczmq version of zproto gsl templates

In order to generate the zgossip codec in go (rather than wrap zgossip_msg in czmq), I need to make a version of the zproto template for go that works with goczmq.

Clean up Flags

More -> FlagMore
add FlagNone
Reuse -> FlagReuse
DontWait -> FlagDontWait

Problem: Poller constructor requires at least one socket.

Is there a way I can create a poller and not have to add a reader/socket when creating it?With the native implementation, I usually pass NULL to zpoller_new then call zpoller_add later.

Outdated documentation in poller.go

This https://github.com/zeromq/goczmq/blob/master/poller.go#L59, says "Remove removes a zsock from Poller".

No more zsock in goczmq.

runtime: found in object at *(0xc82121bdf8+0x20)

libzmq 4.1.3
libczmq 3.0.2
go 1.5/1.5.1 and built from master (6f77278)

I observe this crash periodically (similar to pebbe/zmq2#3 ):

runtime: pointer 0xc821843680 to unused region of spanidx=0xc21 span.start=0xc8210aa000 span.li
mit=0xc8210ac000 span.state=0
runtime: found in object at *(0xc82121bdf8+0x20)
object=0xc82121bdf8 k=0x641090d s.start*_PageSize=0xc82121a000 s.limit=0xc82122ff80 s.sizeclass
=15 s.elemsize=224
 *(object+0) = 0xc8206c3c20
 *(object+8) = 0xc8206c3f20
 *(object+16) = 0xc8203cce40
 *(object+24) = 0xc8206c2d20
 *(object+32) = 0xc821843680 <==
 *(object+40) = 0x20d
 *(object+48) = 0x7fded2ce0598
 *(object+56) = 0xc8201b9da0
 *(object+64) = 0x240
 *(object+72) = 0x2
 *(object+80) = 0x3
 *(object+88) = 0x2
 *(object+96) = 0xc8203d8830
 *(object+104) = 0xc820845260
 *(object+112) = 0xc821843680
 *(object+120) = 0x20d
 *(object+128) = 0x20d
 *(object+136) = 0xc820168480
 *(object+144) = 0x20d
 *(object+152) = 0xc8205f92c0
 *(object+160) = 0x3
 *(object+168) = 0x3
 *(object+176) = 0x30003
 *(object+184) = 0xc82121bf68
 *(object+192) = 0xc82121bf50
 *(object+200) = 0xc82121be68
 *(object+208) = 0xc8206c3c20
 *(object+216) = 0x4a1c17


fatal error: found bad pointer in Go heap (incorrect use of unsafe or cgo?)
runtime stack:
runtime.throw(0xc84600, 0x3e)
        /usr/local/go/src/runtime/panic.go:527 +0x90
runtime.heapBitsForObject(0xc821843680, 0xc82121bdf8, 0x20, 0x0, 0x0, 0x0, 0x7fded2c64770)
        /usr/local/go/src/runtime/mbitmap.go:231 +0x412
runtime.scanblock(0xc82121bdf8, 0x178, 0xcb6a68, 0xc820021c20)
        /usr/local/go/src/runtime/mgcmark.go:698 +0xfb
runtime.scanframeworker(0x7fdeafffeba8, 0x0, 0xc820021c20)
        /usr/local/go/src/runtime/mgcmark.go:521 +0x14c
runtime.scanstack.func1(0x7fdeafffeba8, 0x0, 0x7fded2d000000101)
        /usr/local/go/src/runtime/mgcmark.go:440 +0x65
runtime.gentraceback(0x435074, 0xc82121bc38, 0x0, 0xc8202f8000, 0x0, 0x0, 0x7fffffff, 0x7fdeaff
fecc8, 0x0, 0x0, ...)
        /usr/local/go/src/runtime/traceback.go:338 +0xc77
runtime.scanstack(0xc8202f8000)
        /usr/local/go/src/runtime/mgcmark.go:463 +0x38e
runtime.scang(0xc8202f8000)
        /usr/local/go/src/runtime/proc1.go:422 +0xf3
runtime.markroot(0xc820018060, 0x7fde000000ad)
        /usr/local/go/src/runtime/mgcmark.go:110 +0x1da
runtime.parfordo(0xc820018060)
        /usr/local/go/src/runtime/parfor.go:95 +0x12a
runtime.gcscan_m()
        /usr/local/go/src/runtime/mgcmark.go:36 +0xc9
runtime.gc.func2()
        /usr/local/go/src/runtime/mgc.go:1046 +0xe2
runtime.systemstack(0xc82001e000)
        /usr/local/go/src/runtime/asm_amd64.s:262 +0x79
runtime.mstart()
        /usr/local/go/src/runtime/proc1.go:674
goroutine 526 [garbage collection scan]:
runtime.systemstack_switch()
        /usr/local/go/src/runtime/asm_amd64.s:216 fp=0xc820413c98 sp=0xc820413c90
runtime.gc(0x0)
        /usr/local/go/src/runtime/mgc.go:1055 +0x1e3 fp=0xc820413f90 sp=0xc820413c98
runtime.backgroundgc()
        /usr/local/go/src/runtime/mgc.go:937 +0x3d fp=0xc820413fc0 sp=0xc820413f90
runtime.goexit()
        /usr/local/go/src/runtime/asm_amd64.s:1805 +0x1 fp=0xc820413fc8 sp=0xc820413fc0
created by runtime.startGC
        /usr/local/go/src/runtime/mgc.go:910 +0x186
...

The only Cgo calls I see in stack are:

...
goroutine 214 [runnable, locked to thread]:
github.com/zeromq/goczmq._Cfunc_zframe_send(0xc8201fd4a8, 0x7fdec4004160, 0x7fde00000000, 0xc80
0000000)
        github.com/zeromq/goczmq/_obj/_cgo_gotypes.go:554 +0x39
github.com/zeromq/goczmq.(*Sock).SendFrame(0xc8202f3540, 0xc821bd3680, 0x20d, 0x240, 0x0, 0x0,
0x0)
        /home/demyan/repos/gorepos/src/github.com/zeromq/goczmq/sock.go:249 +0x16d
github.com/zeromq/goczmq.(*Sock).SendMessage(0xc8202f3540, 0xc82008ba90, 0x3, 0x3, 0x0, 0x0)
        /home/demyan/repos/gorepos/src/github.com/zeromq/goczmq/sock.go:299 +0xfc
github.com/demyan/mm/kernel.(*Worker).ZmqPushLoopRun(0xc820206300)
        /home/demyan/repos/gorepos/src/github.com/demyan/mm/kernel/worker.go:278 +0x12c
created by github.com/demyan/mm/kernel.(*Worker).Run
        /home/demyan/repos/gorepos/src/github.com/demyan/mm/kernel/worker.go:120 +0x4f
goroutine 215 [syscall, locked to thread]:
github.com/zeromq/goczmq._Cfunc_zpoller_wait(0x7fdec4004940, 0x1f4, 0x0)
        github.com/zeromq/goczmq/_obj/_cgo_gotypes.go:605 +0x3a
github.com/zeromq/goczmq.(*Poller).Wait(0xc8203d4160, 0x1f4, 0xc820c22f0f)
        /home/demyan/repos/gorepos/src/github.com/zeromq/goczmq/poller.go:87 +0x83
github.com/demyan/mm/kernel.(*Worker).ZmqPullLoopRun(0xc820206300)
        /home/demyan/repos/gorepos/src/github.com/demyan/mm/kernel/worker.go:306 +0x1de
created by github.com/demyan/mm/kernel.(*Worker).Run
        /home/demyan/repos/gorepos/src/github.com/demyan/mm/kernel/worker.go:121 +0x74
...

cert.go: warning: control reaches end of non-void function

Set_meta is defined as returning int in cert.go:

int Set_meta(zcert_t *self, const char *key, const char *value) {zcert_set_meta(self, key, value);}

This results in a warning in an otherwise clean compilation.

vendor/github.com/zeromq/goczmq/cert.go:6:99: warning: control reaches end of non-void function [-Wreturn-type]

The only thing Set_meta does is call zcert_set_meta:

//  Set certificate metadata from formatted string.
CZMQ_EXPORT void
    zcert_set_meta (zcert_t *self, const char *name, const char *format, ...);

Redefining Set_meta with a void return seems reasonable.

Problem: some socket options should accept []byte, not string

Socket options such as the curve pub/private keys currently accept strings, these should accept byte buffers instead

Additionally, some boolean options currently accept an int, those should be changed to bools

GoMaxProcs = 1 results in extreme slowness when interacting with channels

When channels are involved in the app, GOMAXPROCS being 1 results in very slow performance.
a higher GOMAXPROCS setting dramatically increases this:

Case in point:
go test -test.run="TestChanneler" can take several seconds to run, ranging from anywhere between 1 and 20 seconds on my machine
GOMAXPROCS=8 go test -test.run="TestChanneler" on the other hand is consistently around 0.011s, which is MUCH more reasonable and in line with expectations.

I've noticed similar patterns in my production application and I suspect it might have to do with czmq keeping a goroutine permanently busy, thus leaving go with no goroutines to do work on.

Channels test fail on windows

I commented out all other tests to narrow down which tests were failing. Here is the output

$ go test -v
=== RUN TestDealerRouterChanneler
--- PASS: TestDealerRouterChanneler (0.01s)
=== RUN: ExampleChanneler_output
--- PASS: ExampleChanneler_output (0.01s)
PASS
E: 15-06-14 00:53:42 dangling 'PUSH' socket created at C:/Users/ben.aldrich/go/src/github.com/zeromq/goczmq/sock.go:184
Assertion failed: Successful WSASTARTUP not yet performed (signaler.cpp:183)
Exception 0x40000015 0x697bc8a0 0x7fefe212ae0 0x7fefd7d940d
PC=0x7fefd7d940d
signal arrived during cgo execution

syscall.ExitProcess(0xc000000000)
        c:/go/src/syscall/zsyscall_windows.go:260 +0x63
syscall.Exit(0x0)
        c:/go/src/syscall/syscall_windows.go:227 +0x30
os.Exit(0x0)
        c:/go/src/os/proc.go:49 +0x2f
main.main()
        github.com/zeromq/goczmq/_test/_testmain.go:56 +0x1ea

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
        c:/go/src/runtime/asm_amd64.s:2232 +0x1

goroutine 11 [runnable, locked to thread]:
github.com/zeromq/goczmq._Cfunc_zsock_destroy_checked(0xc082004ec0, 0x758a60, 0xdb)
        github.com/zeromq/goczmq/_test/_obj_test/_cgo_gotypes.go:379 +0x4c
github.com/zeromq/goczmq.(*Sock).Destroy(0xc082004ec0)
        C:/Users/ben.aldrich/go/src/github.com/zeromq/goczmq/sock.go:410 +0x68
github.com/zeromq/goczmq.(*Channeler).channeler(0xc082010230, 0xc0820426c0, 0xc082042720)
        C:/Users/ben.aldrich/go/src/github.com/zeromq/goczmq/channeler.go:163 +0x425
created by github.com/zeromq/goczmq.newChanneler
        C:/Users/ben.aldrich/go/src/github.com/zeromq/goczmq/channeler.go:185 +0x43e
rax     0x604acdc6
rbx     0x697bc8a0
rcx     0x28bf2f0
rdx     0xb0
rdi     0x6fb1da40
rsi     0x7fefe193fc0
rbp     0x28bfb60
rsp     0x28bf900
r8      0x0
r9      0x0
r10     0x0
r11     0x28bf940
r12     0x6fb1da30
r13     0x6fb1da38
r14     0x77657be0
r15     0x77652670
rip     0x7fefd7d940d
rflags  0x7fe00000206
cs      0x33
fs      0x53
gs      0x2b
exit status 2
FAIL    github.com/zeromq/goczmq        0.280s

This is on windows 7 with:
zeromq 4.0.5
czmq 3.0.1
libsodium 1.0.3

Error "ZMQ_SUBSCRIBE is not valid on XSUB sockets" when creating NewXSubChanneler

I am not able to create a NewXSubChanneler. It seems like the subscription argument should not be here.

package main

import (
    "github.com/zeromq/goczmq"
    "log"
)

func main() {
    sub := goczmq.NewXSubChanneler("tcp://127.0.0.1:5000", "" /* empty subscription to get all messages */)
    defer sub.Destroy()
    for msg := range sub.RecvChan {
            log.Printf("Got message:\n\t%#v\n", msg)
    }       
}

Running this gives the following output:

% ./xsub 
ZMQ_SUBSCRIBE is not valid on XSUB sockets
xsub: src/zsock_option.c:906: zsock_set_subscribe: Assertion `0' failed.
SIGABRT: abort
PC=0x7f481b5ebcc9 m=0
signal arrived during cgo execution

goroutine 6 [syscall, locked to thread]:
runtime.cgocall(0x4073b0, 0xc82004bd20, 0x0)
        /usr/lib/google-golang/src/runtime/cgocall.go:120 +0x11b fp=0xc82004bcf0 sp=0xc82004bcc0
github.com/zeromq/goczmq._Cfunc_zsock_set_subscribe(0x8c07f0, 0x8c03f0)
        github.com/zeromq/goczmq/_obj/_cgo_gotypes.go:1563 +0x31 fp=0xc82004bd20 sp=0xc82004bcf0
github.com/zeromq/goczmq.(*Sock).SetSubscribe(0xc82000e500, 0x0, 0x0)
        /usr/local/google/home/swast/gocode/src/github.com/zeromq/goczmq/sock_option.go:297 +0x46 fp=0xc82004bd40 sp=0xc82004bd20
github.com/zeromq/goczmq.(*Channeler).actor(0xc8200120e0, 0xc820022180)
        /usr/local/google/home/swast/gocode/src/github.com/zeromq/goczmq/channeler.go:65 +0xb7a fp=0xc82004bfa0 sp=0xc82004bd40
runtime.goexit()
        /usr/lib/google-golang/src/runtime/asm_amd64.s:1696 +0x1 fp=0xc82004bfa8 sp=0xc82004bfa0
created by github.com/zeromq/goczmq.newChanneler
        /usr/local/google/home/swast/gocode/src/github.com/zeromq/goczmq/channeler.go:186 +0x419

goroutine 1 [chan receive]:
main.main()
        /usr/local/google/home/swast/gocode/src/github.com/tswast/xsub/main.go:11 +0xcf

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
        /usr/lib/google-golang/src/runtime/asm_amd64.s:1696 +0x1

goroutine 5 [select]:
github.com/zeromq/goczmq.(*Channeler).channeler(0xc8200120e0, 0xc8200220c0, 0xc820022120)
        /usr/local/google/home/swast/gocode/src/github.com/zeromq/goczmq/channeler.go:140 +0x527
created by github.com/zeromq/goczmq.newChanneler
        /usr/local/google/home/swast/gocode/src/github.com/zeromq/goczmq/channeler.go:185 +0x3ed

rax    0x0
rbx    0x7f481c04d000
rcx    0xffffffffffffffff
rdx    0x6
rdi    0x37e6
rsi    0x37e6
rbp    0x7f481b735830
rsp    0x7ffe3b08f0a8
r8     0xfefefefefefefe00
r9     0x8c0410
r10    0x8
r11    0x202
r12    0x7f481bc2189e
r13    0x7f481bc20e60
r14    0x3
r15    0x8
rip    0x7f481b5ebcc9
rflags 0x202
cs     0x33
fs     0x0
gs     0x0

It works fine if I remove the X and just create a NewSubChanneler.

goczmq prevents signals from being received

When any socket is initialized using goczmq, signal.Notify ceases working and no signals will ever be received on the notify channel

Code:

package main

import (
    "fmt"
    "os"
    "os/signal"
    "syscall"

    zmq "github.com/zeromq/goczmq"
)

func main() {
    // Signal notifiers
    c := make(chan os.Signal, 2)
    signal.Notify(c, os.Interrupt, syscall.SIGTERM)

    _, _ = zmq.NewROUTER(">tcp://0.0.0.0:*")

    <-c
    fmt.Println("Done")
}

if zmq.NewROUTER is removed and the zmq import removed, the signal handler will work again

Problem: TestPushPullChanneler randomly fails (crash)

Steps to reproduce:
go test -v -run TestPushPullChanneler

This test randomly crashes with the following callstack:

➜ goczmq git:(master) ✗ go test -v -run TestPushPullChanneler

=== RUN   TestPushPullChanneler
goczmq.test: src/zsys.c:179: zsys_init: Assertion `!s_process_ctx' failed.
SIGABRT: abort
PC=0x7f1904a71418 m=4
signal arrived during cgo execution

goroutine 23 [syscall, locked to thread]:
runtime.cgocall(0x582480, 0xc8200cad18, 0xc800000000)
    /usr/lib/go-1.6/src/runtime/cgocall.go:123 +0x11b fp=0xc8200cacc0 sp=0xc8200cac90
github.com/goczmq._Cfunc_zsock_new_checked(0x8, 0x7f18f80008c0, 0xc3, 0x0)
    github.com/goczmq/_test/_obj_test/_cgo_gotypes.go:924 +0x42 fp=0xc8200cad18 sp=0xc8200cacc0
github.com/goczmq.NewSock(0x8, 0x0)
    /home/cyrille/code/go/workspace/src/github.com/goczmq/sock.go:80 +0x1f0 fp=0xc8200cada8 sp=0xc8200cad18
github.com/goczmq.NewPush(0xc820078a50, 0x21, 0x0, 0x0, 0x0)
    /home/cyrille/code/go/workspace/src/github.com/goczmq/sock.go:195 +0x2c fp=0xc8200cade8 sp=0xc8200cada8
github.com/goczmq.(*Channeler).channeler(0xc82006c380, 0xc820070420, 0xc820070480)
    /home/cyrille/code/go/workspace/src/github.com/goczmq/channeler.go:128 +0x4d fp=0xc8200caf98 sp=0xc8200cade8
runtime.goexit()
    /usr/lib/go-1.6/src/runtime/asm_amd64.s:1998 +0x1 fp=0xc8200cafa0 sp=0xc8200caf98
created by github.com/goczmq.newChanneler
    /home/cyrille/code/go/workspace/src/github.com/goczmq/channeler.go:185 +0x3f2

goroutine 1 [chan receive]:
testing.RunTests(0x670590, 0x916c20, 0x4c, 0x4c, 0xc820072801)
    /usr/lib/go-1.6/src/testing/testing.go:583 +0x8d2
testing.(*M).Run(0xc82004def8, 0xf)
    /usr/lib/go-1.6/src/testing/testing.go:515 +0x81
main.main()
    github.com/goczmq/_test/_testmain.go:236 +0x117

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/lib/go-1.6/src/runtime/asm_amd64.s:1998 +0x1

goroutine 20 [chan send]:
github.com/goczmq.TestPushPullChanneler(0xc8200a0360)
    /home/cyrille/code/go/workspace/src/github.com/goczmq/channeler_test.go:17 +0x1c2
testing.tRunner(0xc8200a0360, 0x916ce0)
    /usr/lib/go-1.6/src/testing/testing.go:473 +0x98
created by testing.RunTests
    /usr/lib/go-1.6/src/testing/testing.go:582 +0x892

goroutine 21 [runnable, locked to thread]:
github.com/goczmq._Cfunc_zsock_new_checked(0x8, 0x7f18f40008c0, 0xc3, 0x7f18f4000910)
    github.com/goczmq/_test/_obj_test/_cgo_gotypes.go:924 +0x42
github.com/goczmq.NewSock(0x8, 0x0)
    /home/cyrille/code/go/workspace/src/github.com/goczmq/sock.go:80 +0x1f0
github.com/goczmq.NewPush(0xc8200789f0, 0x21, 0x4922be, 0x0, 0x0)
    /home/cyrille/code/go/workspace/src/github.com/goczmq/sock.go:195 +0x2c
github.com/goczmq.(*Channeler).channeler(0xc82006c310, 0xc820070300, 0xc820070360)
    /home/cyrille/code/go/workspace/src/github.com/goczmq/channeler.go:128 +0x4d
created by github.com/goczmq.newChanneler
    /home/cyrille/code/go/workspace/src/github.com/goczmq/channeler.go:185 +0x3f2

goroutine 22 [runnable, locked to thread]:
github.com/goczmq._Cfunc_free(0x7f18fc000a20)
    github.com/goczmq/_test/_obj_test/_cgo_gotypes.go:260 +0x36
github.com/goczmq.NewSock(0x0, 0xc820014280)
    /home/cyrille/code/go/workspace/src/github.com/goczmq/sock.go:81 +0x21a
github.com/goczmq.NewPair(0xc82000a180, 0x29, 0xc82003de40, 0x0, 0x0)
    /home/cyrille/code/go/workspace/src/github.com/goczmq/sock.go:230 +0x2c
github.com/goczmq.(*Channeler).actor(0xc82006c310, 0xc8200703c0)
    /home/cyrille/code/go/workspace/src/github.com/goczmq/channeler.go:35 +0x13c
created by github.com/goczmq.newChanneler
    /home/cyrille/code/go/workspace/src/github.com/goczmq/channeler.go:186 +0x41e

goroutine 24 [runnable, locked to thread]:
github.com/goczmq._Cfunc_zsock_new_checked(0x0, 0x16e5330, 0xe6, 0x16e4c20)
    github.com/goczmq/_test/_obj_test/_cgo_gotypes.go:924 +0x42
github.com/goczmq.NewSock(0x0, 0x0)
    /home/cyrille/code/go/workspace/src/github.com/goczmq/sock.go:80 +0x1f0
github.com/goczmq.NewPair(0xc820078a80, 0x29, 0xc820039e40, 0x0, 0x0)
    /home/cyrille/code/go/workspace/src/github.com/goczmq/sock.go:230 +0x2c
github.com/goczmq.(*Channeler).actor(0xc82006c380, 0xc8200704e0)
    /home/cyrille/code/go/workspace/src/github.com/goczmq/channeler.go:35 +0x13c
created by github.com/goczmq.newChanneler
    /home/cyrille/code/go/workspace/src/github.com/goczmq/channeler.go:186 +0x41e

rax    0x0
rbx    0x7f19054de000
rcx    0x7f1904a71418
rdx    0x6
rdi    0x7f72
rsi    0x7f77
rbp    0x7f19050adfb5
rsp    0x7f1902ac4bf8
r8     0x7f18f8000990
r9     0xfefefefeff092d00
r10    0x8
r11    0x206
r12    0xb3
r13    0x7f19050af8d8
r14    0x3
r15    0x8
rip    0x7f1904a71418
rflags 0x206
cs     0x33
fs     0x0
gs     0x0
exit status 2
FAIL    github.com/goczmq   0.006s

Problem: io.ReadWriter only supports strict lockstep with Dealer / Router

Currently a router sock stores the id of the last message received from a dealer and then uses that to transparently handle routing replies back (when using the io.ReadWriter interface).

It would be nice to extend this convenience to non lock-step patterns - e.g., receive 10 requests from Dealer(s), then send 10 replies back, etc.

C.free() must be called to free the memory allocated by C.CString()

I add some comment in #181. Long story short, you must call C.free() for EVERy C.CString(), not only for the ones using literal strings.

Can't shutdown CZMQ zsys layer

The zsys_shutdown function is called at process termination (through atexit). Exposing this function to callers will allow the CZMQ zsys layer to be shut down manually and any resources allocated by zsys can be freed.

This is useful in a couple situations: (1) no more CZMQ activity will take place but the process will keep running, and (2) we're about to exec and want to free any resources we don't want going forward.

Problem: no documentation and some code uncommented

In order to comply with contribution guidelines, uncommented code needs to be commented in order to pass style guideline checks.

Additionally, the documentation should be updated. For now, I'm thinking of going with a README.md that includes an introductory section about project goals, and a brief explanation of how I am wrapping zactor classes. After that section will be auto-generated documentation until the API stabilizes enough to make writing a better guide to goczmq worth it.

Poller.Wait() crashes if called after Poller.Destroy()

I found that Poller.Wait() will cause a panic (segfault) if invoked after Poller.Destroy().

Here's some sample code using goroutines (where I would close a Poller in a different goroutine):

package main

import (
  czmq "github.com/zeromq/goczmq"
  "log"
  "os"
  "time"
)

func main() {
  log.SetOutput(os.Stdout)
  sock, _ := czmq.NewRep("inproc://foo")
  poller, _ := czmq.NewPoller(sock)

  go func() { 
    time.Sleep(500 * time.Millisecond)
    log.Printf("Destroying sock now\n")
    sock.Destroy()

    time.Sleep(500 * time.Millisecond)
    log.Printf("Destroying poller now\n")
    poller.Destroy() 
  }() 
  log.Printf("poller.Wait(...)\n")
  poller.Wait(3000)
  log.Printf("poller.Wait(...)\n")
  poller.Wait(3000)
}

Here's a single-goroutine example:

  package main

  import (
    czmq "github.com/zeromq/goczmq"
    "log"
    "os"
  )

  func main() {
    log.SetOutput(os.Stdout)
    sock, _ := czmq.NewRep("inproc://foo")
    poller, _ := czmq.NewPoller(sock)

    log.Printf("poller.Wait(...)\n")
    poller.Wait(3000)
    log.Printf("poller.Destroy()\n")
    poller.Destroy() 
    log.Printf("poller.Wait(...)\n")
    poller.Wait(3000)
  }

The panic output looks like this:

2015/07/19 15:09:01 poller.Wait(...)
2015/07/19 15:09:04 poller.Destroy()
2015/07/19 15:09:04 poller.Wait(...)
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x23 pc=0x7f0947776e0e]

runtime stack:
runtime.gothrow(0x51df70, 0x2a)
        /usr/lib/go/src/runtime/panic.go:503 +0x8e
runtime.sigpanic()
        /usr/lib/go/src/runtime/sigpanic_unix.go:14 +0x5e

goroutine 1 [syscall, locked to thread]:
runtime.cgocall_errno(0x406480, 0xc208083e68, 0xc200000000)
        /usr/lib/go/src/runtime/cgocall.go:130 +0xf5 fp=0xc208083e48 sp=0xc208083e20
github.com/zeromq/goczmq._Cfunc_zpoller_wait(0x0, 0xbb8, 0x0)
        github.com/zeromq/goczmq/_obj/_cgo_gotypes.go:332 +0x44 fp=0xc208083e68 sp=0xc208083e48
github.com/zeromq/goczmq.(*Poller).Wait(0xc208020060, 0xbb8, 0x0)
        /home/jls/projects/go/src/github.com/zeromq/goczmq/poller.go:87 +0x373 fp=0xc208083f28 sp=0xc208083e68
main.main()
        /home/jls/projects/experiments/go/zmq2.go:19 +0x1b4 fp=0xc208083f98 sp=0xc208083f28
runtime.main()
        /usr/lib/go/src/runtime/proc.go:63 +0xf3 fp=0xc208083fe0 sp=0xc208083f98
runtime.goexit()
        /usr/lib/go/src/runtime/asm_amd64.s:2232 +0x1 fp=0xc208083fe8 sp=0xc208083fe0

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
        /usr/lib/go/src/runtime/asm_amd64.s:2232 +0x1

Problem: I want to make backwards incompatible changes.

I would like to start adding support for the new thread safe sockets to goczmq:

ZMQ_RADAR / ZMQ_DISH
ZMQ_SCATTER / ZMQ_GATHER
ZMQ_CLIENT / ZMQ_SERVER

This would of course break building goczmq against the current stable release of libzmq and czmq.

I am thinking about using gopkg.in ( http://labix.org/gopkg.in ) to handle this, the same way oliver's elastic library does for dealing with multiple incompatible versions of the elasticsearch API ( see: https://github.com/olivere/elastic ).

I'm putting this issue here to solicit feedback and give a heads up.

Sock.RecvFrame() crashes w/ sigabrt if called after Sock.Destroy()

Background: Similar problem likely to #145

This probably also affects RecvMessage, SendFrame, and SendMessage, but I haven't checked.

@PSG-Luna You had concerns about using panic(), and I think I agree with you. Any thoughts on the type of error? I was thinking something like:

type SocketIsDestroyed struct {}

func (e *SocketIsDestroyed) Error() string {
  return "Socket was destroyed, it cannot be used anymore."
}

Thoughts? I can provide patches.

Problem: RecvChan is not closed when router is destroyed

my application is receiving messages in a go subroutine:

router := NewRouterChanneler("inproc://channelerouter")
resp := <-router.RecvChan

my application catches signal interrupt (Ctr-C) and wants to exit properly by closing/destroying resources:

router.Destroy()

Problem:
The go routine is still hanging, waiting for data on router.RecvChan

Problem: Too Many Z's

"z" prefixing everything makes sense in a language like C where there aren't namespaces.
in go, it's just a character we have to type in front of all our names for no particular reason
refactor to remove zprefixes from calls as we already have a namespace.

TestChanneler sometimes times out

From travis-ci:

--- FAIL: TestChanneler (0.07 seconds)

channeler_test.go:51: Timeout while waiting for send channel

NOTE: has not happened locally, doesn't always happen on travis.

Support for authentication with channeler

Are there plans to support socket options and authentication using channelers?

Common scenario for me is to have a router with authentication and then use a dealers with go routines to pull the data off. The Channeler approach seems a lot more robust but I can't enable authentication of the external router socket.

Problem: uint64 options not supported yet

uint64 options in sockopts.xml are not supported yet.

Problem: "key" type options not supported

"key" type options in sockopts.xml are currently not supported.

Cross platform builds for Windows and Linux fail from OS X build

I'm trying to build a statically built binary to run across all the major platforms, but this isn't working with Windows or Linux (built from my OS X machine).

Windows

$ CGO_ENABLED=1 GOOS=windows GOARCH=amd64 go build -a -tags netgo -ldflags '-w' -o client .
# github.com/zeromq/goczmq
warning: unknown warning option '-Wno-pedantic-ms-format'; did you mean '-Wno-pedantic'? [-Wunknown-warning-option]
../../../../../zeromq/goczmq/auth.go:4:10: fatal error: 'czmq.h' file not found
#include "czmq.h"
         ^
1 warning and 1 error generated.

Linux

$ CGO_ENABLED=1 GOOS=linux GOARCH=amd64 go build -a -tags netgo -ldflags '-w' -o client .
# runtime/cgo
ld: unknown option: --build-id=none
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Darwin

$ CGO_ENABLED=1 GOOS=darwin GOARCH=amd64 go build -a -tags netgo -ldflags '-w' -o client .
$ # built fine

Next steps

I'm going to try out the old way of doing this tomorrow (using Gimme to fetch the right versions of go), but it would cool to figure out if/where this can be addressed in goczmq to make cross platform builds work well.

NewROUTER fails when hostname is 'localhost'

The following line fails:

routerSock, err := czmq.NewROUTER("tcp://localhost:5559")

And the error message is:

goroutine 16 [running]:
runtime.panic(0x40c2f80, 0xc208000190)
        /usr/local/go/src/pkg/runtime/panic.c:279 +0xf5
main.main()
        /Users/dhanush/golang/src/github.com/zeromq/goczmq/examples/extended-req-rep/rrbroker.go:15 +0x176

goroutine 17 [runnable]:
runtime.MHeap_Scavenger()
        /usr/local/go/src/pkg/runtime/mheap.c:507
runtime.goexit()
        /usr/local/go/src/pkg/runtime/proc.c:1445

goroutine 18 [runnable]:
bgsweep()
        /usr/local/go/src/pkg/runtime/mgc0.c:1976
runtime.goexit()
        /usr/local/go/src/pkg/runtime/proc.c:1445

goroutine 19 [runnable]:
runfinq()
        /usr/local/go/src/pkg/runtime/mgc0.c:2606
runtime.goexit()
        /usr/local/go/src/pkg/runtime/proc.c:1445

goroutine 17 [syscall]:
runtime.goexit()
        /usr/local/go/src/pkg/runtime/proc.c:1445
exit status 2

My code lives here: http://play.golang.org/p/vP1qLyxYwx

Error return in listener.NewCertFromFile is hardcoded to nil

Error return in listener.NewCertFromFile is hardcoded to nil. Thus there is no convenient way to tell whether the cert file is valid. In addition, there is no way to check for validity without the possibility of a panic exception being thrown, e.g. there is no IsValid() call.

Suggest checking the cert returned from C.zcert_load() for validity and returning an error if not e.g:

// NewCertFromFile Load loads a Cert from files <--- Cert.go#49
func NewCertFromFile(filename string) (*Cert, error) {
cert := C.zcert_load(C.CString(filename))
return &Cert{
zcertT: cert,
}, nil <-- return error if cert is invalid
}

Thread Safe Channels Example Fails

$ go run thread_safe_channel.go
2015/08/16 09:57:27 router created and bound
2015/08/16 09:57:27 dealer created and connected
Assertion failed: (!s_process_ctx), function zsys_init, file src/zsys.c, line 179.
SIGABRT: abort
PC=0x7fff9510f286
signal arrived during cgo execution

goroutine 6 [syscall, locked to thread]:
runtime.cgocall_errno(0x4001850, 0xc208059cf0, 0x0)
    /usr/local/Cellar/go/1.4.2/libexec/src/runtime/cgocall.go:130 +0xf5 fp=0xc208059cd0 sp=0xc208059ca8
github.com/zeromq/goczmq._Cfunc_zsock_new_checked(0x0, 0x5000200, 0xdb, 0x0)
    github.com/zeromq/goczmq/_obj/_cgo_gotypes.go:479 +0x44 fp=0xc208059cf0 sp=0xc208059cd0
github.com/zeromq/goczmq.NewSock(0x0, 0xc20803a300)
    /Users/kyle6475/code/src/github.com/zeromq/goczmq/sock.go:81 +0x189 fp=0xc208059d68 sp=0xc208059cf0
github.com/zeromq/goczmq.NewPair(0xc20803a300, 0x29, 0xc208059e98, 0x0, 0x0)
    /Users/kyle6475/code/src/github.com/zeromq/goczmq/sock.go:219 +0x39 fp=0xc208059da8 sp=0xc208059d68
github.com/zeromq/goczmq.(*Channeler).actor(0xc208010070, 0xc2080500c0)
    /Users/kyle6475/code/src/github.com/zeromq/goczmq/channeler.go:35 +0x141 fp=0xc208059fd0 sp=0xc208059da8
runtime.goexit()
    /usr/local/Cellar/go/1.4.2/libexec/src/runtime/asm_amd64.s:2232 +0x1 fp=0xc208059fd8 sp=0xc208059fd0
created by github.com/zeromq/goczmq.newChanneler
    /Users/kyle6475/code/src/github.com/zeromq/goczmq/channeler.go:186 +0x45b

goroutine 1 [chan send]:
main.main()
    /Users/kyle6475/code/src/github.com/rgbkrk/junkie/thread_safe_channel.go:25 +0x2fe

goroutine 5 [syscall, locked to thread]:
github.com/zeromq/goczmq._Cfunc_zsock_attach(0x5000470, 0x54003c0, 0x5400300, 0x0)
    github.com/zeromq/goczmq/_obj/_cgo_gotypes.go:347 +0x43
github.com/zeromq/goczmq.(*Sock).Attach(0xc20805bfa8, 0x2, 0x2, 0x4016062, 0xc20805bf30, 0x0)
    /Users/kyle6475/code/src/github.com/zeromq/goczmq/sock.go:132 +0x68
created by github.com/zeromq/goczmq.newChanneler
    /Users/kyle6475/code/src/github.com/zeromq/goczmq/channeler.go:185 +0x437

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/local/Cellar/go/1.4.2/libexec/src/runtime/asm_amd64.s:2232 +0x1

goroutine 7 [runnable, locked to thread]:
github.com/zeromq/goczmq._Cfunc_zsock_attach(0x5200040, 0x52000e0, 0x5200000, 0x0)
    github.com/zeromq/goczmq/_obj/_cgo_gotypes.go:347 +0x43
github.com/zeromq/goczmq.(*Sock).Attach(0xc208034300, 0xc20803a2d0, 0x21, 0x0, 0x0, 0x0)
    /Users/kyle6475/code/src/github.com/zeromq/goczmq/sock.go:132 +0x68
github.com/zeromq/goczmq.NewPush(0x40f94b0, 0x3, 0xc208054ed8, 0x1, 0x1)
    /Users/kyle6475/code/src/github.com/zeromq/goczmq/sock.go:185 +0x65
github.com/zeromq/goczmq.(*Channeler).channeler(0xc2080100e0, 0xc208050180, 0xc2080501e0)
    /Users/kyle6475/code/src/github.com/zeromq/goczmq/channeler.go:127 +0x4b
created by github.com/zeromq/goczmq.newChanneler
    /Users/kyle6475/code/src/github.com/zeromq/goczmq/channeler.go:185 +0x437
2015/08/16 09:57:27 dealer sent 'Hello'

goroutine 8 [syscall, locked to thread]:
github.com/zeromq/goczmq._Cfunc_zframe_recv(0x52003d0, 0x0)
    github.com/zeromq/goczmq/_obj/_cgo_gotypes.go:305 +0x44
github.com/zeromq/goczmq.(*Sock).RecvFrame(0x0, 0x404307a, 0x5200860, 0xffffffff, 0x0, 0x1, 0x1)
    /Users/kyle6475/code/src/github.com/zeromq/goczmq/sock.go:268 +0x72
created by github.com/zeromq/goczmq.newChanneler
    /Users/kyle6475/code/src/github.com/zeromq/goczmq/channeler.go:186 +0x45b

rax     0x0
rbx     0x6
rcx     0x7fff5fbfea58
rdx     0x0
rdi     0x30b
rsi     0x6
rbp     0x7fff5fbfea80
rsp     0x7fff5fbfea58
r8      0x0
r9      0xb3
r10     0x8000000
r11     0x206
r12     0x422303c
r13     0x4370000
r14     0x7fff7846b300
r15     0x4222f8b
rip     0x7fff9510f286
rflags  0x206
cs      0x7
fs      0x0
gs      0x0
exit status 2

Undefined behavior with cgo

Currently, we sometimes directly pass pointers of go objects to C land.
The behaviour of this code happens to work, but is currently not well defined and will change with later go versions.
I propose we start getting rid of these already so we have less work when the next version of go is released (in 6 months from now) that will include a moving garbage collector.

Example: https://github.com/zeromq/goczmq/blob/master/sock.go#L332

Problem: No Simple Examples

The README should provide simple code examples for implemented features near the top.

gossip recv missing

there is no receive/consume analog of gossip.Publish.
that is, you can set a key/value pair but there is no way to see it,
or all of them. the simplest answer would be something like
func (*Gossip) Status() map[string]string
which would return a map of all known k/v pairs.
For extra marks, i would add a way for the app to get new k/v pairs as they publish,
either as a chan of struct { string, string }, or registering a callback function.

C.free() must be called to free the memory allocated by C.CString()

C.free() must be called to free the memory allocated by C.CString(), for example:

func (a *Auth) Verbose() error {
    // Must call C.free()
    v := C.CString("VERBOSE")
    defer C.free(v)
    rc := C.zstr_send(unsafe.Pointer(a.zactorT), v)
    if rc == -1 {
        return ErrActorCmd
    }
    C.zsock_wait(unsafe.Pointer(a.zactorT))

    return nil
}

Sock io.ReadWriter can't handle len(p) < Frame

io.Reader read bytes count is wrong
https://github.com/zeromq/goczmq/blob/master/sock.go#L342
You can see it just return the Frame size, not how many bytes are read into p

We can add such code into testcases for validation.

err = dealerSock.SendFrame([]byte("Hello"), FlagNone)
if err != nil {
    t.Errorf("dealerSock.SendFrame failed: %s", err)
}

b = make([]byte, 2)
n, err = routerSock.Read(b)
if n != 2 {
    t.Errorf("routerSock.Read expected 2 bytes read %d", n)  // routerSock.Read expected 2 bytes read 5
}

Problem: channeler.go has thread safety issues

We are reworking the channeler rather heavily - it will be an API breaking change.
This should be the last API break before declaring the API stable ( Yay! )

Problem: Key Based Auth Didn't Work (and Brian is silly)

Just a heads up I was working out of the wrong repo and accidently pushed cert based auth to master instead of as a pull request.

The good news is CURVE public key auth now works.

I'll close this issue when PSG_Luna verifies I haven't broken anything (it's building and unit tests are passing here)

Problem: No Nice Consistent Way For Dealing Wth Bytes and Strings

Overview:

RecvBytes returns a []byte, flag, error
RecvString returns string, error and no flag

These are inconsistent, and RecvString should return a more flag to be usable with multi part messages.

RecvMessage returns a full message as [][]bytes (and an error)
RecvMultiString returns a full message as a []string and an error

These are consistent, but the names are not so wonderful.

Channeler returns a channel of [][]byte messages, which is great - but any person who would like to get []string back from Channeler will need to write a little code - yesterday we discussed that we could make some utility functions for transposing between [][]byte <-> []string when working with Channeler.

Thoughts:

The utility functions for working with Channeler won't break anything, they are additions.
RecvMessage / RecvMultiString should be named something more consistent, like RecvBytesMessage / RecvStringsMessage (I probably am bad at naming things). This is a breaking change so we should discuss
RecvString should be changed to return string, flag, err like RecvBytes. This is a breaking change so we shold discuss

Thoughts from others welcome, this is just my early morning coffee thoughts on this.

Problem: assertion failure on windows

When running the unit tests on windows (compiling with Mingw), this results in the following output:

$ go test -v
=== RUN TestBeacon
I: 14-10-14 10:17:31 zbeacon: API command=CONFIGURE
I: 14-10-14 10:17:31 zbeacon: using address=192.168.1.4 broadcast=192.168.1.255
I: 14-10-14 10:17:31 zbeacon: configured, hostname=192.168.1.4
I: 14-10-14 10:17:31 zbeacon: API command=CONFIGURE
I: 14-10-14 10:17:31 zbeacon: using address=192.168.1.4 broadcast=192.168.1.255
I: 14-10-14 10:17:31 zbeacon: configured, hostname=192.168.1.4
I: 14-10-14 10:17:31 zbeacon: API command=SUBSCRIBE
I: 14-10-14 10:17:31 zbeacon: API command=PUBLISH
I: 14-10-14 10:17:31 zbeacon: API command=$TERM
I: 14-10-14 10:17:31 zbeacon: API command=$TERM
--- PASS: TestBeacon (0.01 seconds)
        beacon_test.go:39: 192.168.1.4
=== RUN TestGossip
D: 14-10-14 10:17:31 server:     API command=BIND
D: 14-10-14 10:17:31 server:     API command=$TERM
--- PASS: TestGossip (0.02 seconds)
=== RUN TestPoller
--- PASS: TestPoller (0.00 seconds)
=== RUN TestZproxy
I: 14-10-14 10:17:31 zproxy: API command=FRONTEND
I: 14-10-14 10:17:31 zmonitor: - frontend type=PULL attach=inproc://frontend
I: 14-10-14 10:17:31 zproxy: API command=BACKEND
I: 14-10-14 10:17:31 zmonitor: - backend type=PUSH attach=inproc://backend
I: 14-10-14 10:17:31 zproxy: API command=CAPTURE
I: 14-10-14 10:17:31 zproxy: API command=PAUSE
--- PASS: TestZproxy (0.00 seconds)
I: 14-10-14 10:17:31 zproxy: API command=RESUME
=== RUN TestTos
--- PASS: TestTos (0.00 seconds)
=== RUN TestRouterHandover
--- PASS: TestRouterHandover (0.00 seconds)
=== RUN TestRouterMandatory
--- PASS: TestRouterMandatory (0.00 seconds)
=== RUN TestProbeRouter
--- PASS: TestProbeRouter (0.00 seconds)
=== RUN TestReqRelaxed
--- PASS: TestReqRelaxed (0.00 seconds)
=== RUN TestReqCorrelate
--- PASS: TestReqCorrelate (0.00 seconds)
=== RUN TestConflate
--- PASS: TestConflate (0.00 seconds)
=== RUN TestZapDomain
--- PASS: TestZapDomain (0.00 seconds)
=== RUN TestPlainServer
--- PASS: TestPlainServer (0.00 seconds)
=== RUN TestPlainUsername
--- PASS: TestPlainUsername (0.00 seconds)
=== RUN TestPlainPassword
--- PASS: TestPlainPassword (0.00 seconds)
=== RUN TestIpv6
--- PASS: TestIpv6 (0.00 seconds)
=== RUN TestImmediate
--- PASS: TestImmediate (0.00 seconds)
=== RUN TestRouterRaw
--- PASS: TestRouterRaw (0.00 seconds)
=== RUN TestIpv4only
--- PASS: TestIpv4only (0.00 seconds)
=== RUN TestDelayAttachOnConnect
--- PASS: TestDelayAttachOnConnect (0.00 seconds)
=== RUN TestSndhwm
--- PASS: TestSndhwm (0.00 seconds)
=== RUN TestRcvhwm
--- PASS: TestRcvhwm (0.00 seconds)
=== RUN TestAffinity
--- PASS: TestAffinity (0.00 seconds)
=== RUN TestSubscribe
--- PASS: TestSubscribe (0.00 seconds)
=== RUN TestUnsubscribe
--- PASS: TestUnsubscribe (0.00 seconds)
=== RUN TestIdentity
--- PASS: TestIdentity (0.00 seconds)
=== RUN TestRate
--- PASS: TestRate (0.00 seconds)
=== RUN TestRecoveryIvl
--- PASS: TestRecoveryIvl (0.00 seconds)
=== RUN TestSndbuf
--- PASS: TestSndbuf (0.00 seconds)
=== RUN TestRcvbuf
--- PASS: TestRcvbuf (0.00 seconds)
=== RUN TestLinger
--- PASS: TestLinger (0.00 seconds)
=== RUN TestReconnectIvl
--- PASS: TestReconnectIvl (0.00 seconds)
=== RUN TestReconnectIvlMax
--- PASS: TestReconnectIvlMax (0.00 seconds)
=== RUN TestBacklog
--- PASS: TestBacklog (0.00 seconds)
=== RUN TestMaxmsgsize
--- PASS: TestMaxmsgsize (0.00 seconds)
=== RUN TestMulticastHops
--- PASS: TestMulticastHops (0.00 seconds)
=== RUN TestRcvtimeo
--- PASS: TestRcvtimeo (0.00 seconds)
=== RUN TestSndtimeo
--- PASS: TestSndtimeo (0.00 seconds)
=== RUN TestXpubVerbose
--- PASS: TestXpubVerbose (0.00 seconds)
=== RUN TestTcpKeepalive
--- PASS: TestTcpKeepalive (0.00 seconds)
=== RUN TestTcpKeepaliveIdle
--- PASS: TestTcpKeepaliveIdle (0.00 seconds)
=== RUN TestTcpKeepaliveCnt
--- PASS: TestTcpKeepaliveCnt (0.00 seconds)
=== RUN TestTcpKeepaliveIntvl
--- PASS: TestTcpKeepaliveIntvl (0.00 seconds)
=== RUN TestTcpAcceptFilter
--- PASS: TestTcpAcceptFilter (0.00 seconds)
=== RUN TestSock
--- PASS: TestSock (0.00 seconds)
=== RUN TestMessage
--- PASS: TestMessage (0.00 seconds)
=== RUN TestPUBSUB
--- PASS: TestPUBSUB (0.00 seconds)
=== RUN TestREQREP
--- PASS: TestREQREP (0.00 seconds)
=== RUN TestPUSHPULL
--- PASS: TestPUSHPULL (0.00 seconds)
=== RUN TestROUTERDEALER
--- PASS: TestROUTERDEALER (0.00 seconds)
=== RUN TestXSUBXPUB
--- PASS: TestXSUBXPUB (0.00 seconds)
=== RUN TestPAIR
--- PASS: TestPAIR (0.00 seconds)
=== RUN TestSTREAM
--- PASS: TestSTREAM (0.00 seconds)
=== RUN TestPollin
--- PASS: TestPollin (0.00 seconds)
=== RUN TestPollout
--- PASS: TestPollout (0.00 seconds)
PASS
E: 14-10-14 10:17:31 dangling 'PULL' socket created at C:/Synced/PSG/go-workspace/src/github.com/zeromq/goczmq/sock.go:118
Assertion failed: Successful WSASTARTUP not yet performed (signaler.cpp:183)
exit status 255
FAIL    github.com/zeromq/goczmq        5.823s

Building on windows

I am working on a project that requires zeromq on windows and linux. I've got libsodium, zeromq and czmq building for windows. When I go get goczmq I get this error:

$ go get github.com/zeromq/goczmq
# pkg-config --cflags libczmq libzmq libsodium
pkg-config: exec: "pkg-config": executable file not found in %PATH%

Why does it require pkg-config to build? I should mention I am cross compiling all the libs for libsodium, zeromq and czmq. Previously this all worked with zmq4 without czmq.

I tried to install pkg-config but it then complains about libglib-2.0 which I am sure isn't the last dependency. pkg-config looks really hard to build for windows.

Beacon.Recv returns a string, but Beacons are 2 frames

Sample code: https://gist.github.com/jordansissel/3ad77aab81ca92f898a7

The Recv method returns a single string value, but each Beacon appears to be two frames - the IP and the announcement string.

Example, running ./beacon one and ./beacon two:

INFO[0000] New beacon running                            announcement=one
INFO[0001] Received beacon                               announcement=one str=192.168.1.135
INFO[0001] Received beacon                               announcement=one str=two
INFO[0003] Received beacon                               announcement=one str=192.168.1.135
INFO[0003] Received beacon                               announcement=one str=two

Each beacon requires basically 2 Recv() calls because under the hood it invokes zstr_recv. The docs for zbeacon say this:

//  Receive next beacon from a peer. Received beacons are always a 2-frame
//  message containing the ipaddress of the sender, and then the binary
//  beacon data as published by the sender:
//
//      zmsg_t *msg = zmsg_recv (beacon);

I think this means two things:

API change: Beacon.Recv() should return two values: a string (the IP) and a []byte (the announcement)
Internals change: we should call whatever method (zmsg_recv?) that will get us both frames from the request.

Thoughts?

Running goczmq tests / benchmarks SIGABRT

OS: centos 7
x86_64
zmq 4.0.5
czmq 3.0.2
libsodium 1.0.3

  goczmq git:(master) go test -bench=.  
goczmq.test: src/zsockopt.c:482: zsocket_set_curve_secretkey_bin: Assertion `rc == 0 || zmq_errno () == (156384712 + 53)' failed.
SIGABRT: abort
PC=0x7f4af4ce15d7
signal arrived during cgo execution

goroutine 7 [syscall, locked to thread]:
runtime.cgocall_errno(0x406340, 0xc208018e20, 0x0)
    /usr/local/go/src/runtime/cgocall.go:130 +0xf5 fp=0xc208018e00 sp=0xc208018dd8
github.com/zeromq/goczmq._Cfunc_zsocket_set_curve_secretkey_bin(0xdd1120, 0xdd2060)
    github.com/zeromq/goczmq/_test/_obj_test/_cgo_gotypes.go:919 +0x45 fp=0xc208018e20 sp=0xc208018e00
github.com/zeromq/goczmq.(*Cert).Apply(0xc20804e098, 0xc20803b800)
    /home/vrecan/go/src/github.com/zeromq/goczmq/cert.go:76 +0x5e fp=0xc208018e40 sp=0xc208018e20
github.com/zeromq/goczmq.TestAuthCurveAllow(0xc20806e120)
    /home/vrecan/go/src/github.com/zeromq/goczmq/auth_test.go:224 +0x23c fp=0xc208018f78 sp=0xc208018e40
testing.tRunner(0xc20806e120, 0x8b07b0)
    /usr/local/go/src/testing/testing.go:447 +0xbf fp=0xc208018fd0 sp=0xc208018f78
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:2232 +0x1 fp=0xc208018fd8 sp=0xc208018fd0
created by testing.RunTests
    /usr/local/go/src/testing/testing.go:555 +0xa8b

goroutine 1 [chan receive]:
testing.RunTests(0x624820, 0x8b0780, 0x45, 0x45, 0x8c4c01)
    /usr/local/go/src/testing/testing.go:556 +0xad6
testing.(*M).Run(0xc208050460, 0x8af8c0)
    /usr/local/go/src/testing/testing.go:485 +0x6c
main.main()
    github.com/zeromq/goczmq/_test/_testmain.go:228 +0x1d5

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:2232 +0x1

rax     0x0
rbx     0x7f4af5bf0000
rcx     0xffffffffffffffff
rdx     0x6
rdi     0x6814
rsi     0x6814
rbp     0x7f4af4e2a128
rsp     0x7fff264b1da8
r8      0x1
r9      0xfefefefffeff092d
r10     0x8
r11     0x206
r12     0x7f4af57b2848
r13     0x7f4af57c22e0
r14     0x2
r15     0xc20803c780
rip     0x7f4af4ce15d7
rflags  0x206
cs      0x33
fs      0x0
gs      0x0
exit status 2

Failure to go get

Hi folks,

I'm seeing this when I go get this package:

$ go get github.com/zeromq/goczmq

github.com/zeromq/goczmq

could not determine kind of name for C.zsock_destroy_checked
could not determine kind of name for C.zsock_new_checked

I'm sure I'm doing something wrong, but have no idea where to begin to track the problem.

Here's my go version:
$ go version
go version go1.4.2 linux/amd64

Thanks!

-chuck

(*Cert).Apply(...) crashes

I noticed this tonight while trying to resurrect some old code and found its test suite fails when I call cert.Apply(sock). Checking the goczmq test suite, it looks like the same thing fails (yay tests!)

I haven't yet dug into why this is failing.

# OSX 10.11
% brew info czmq zeromq libsodium | grep ', HEAD'
czmq: stable 3.0.2 (bottled), HEAD
zeromq: stable 4.1.3 (bottled), HEAD
libsodium: stable 1.0.6 (bottled), HEAD

% clang --version
Apple LLVM version 7.0.0 (clang-700.1.76)
Target: x86_64-apple-darwin15.0.0
Thread model: posix

% go version
go version go1.5.1 darwin/amd64

Test failure output

% go test .
Assertion failed: (rc == 0 || zmq_errno () == ETERM), function zsocket_set_curve_secretkey_bin, file src/zsockopt.c, line 482.
SIGABRT: abort
PC=0x7fff8f9320ae m=0
signal arrived during cgo execution

goroutine 7 [syscall, locked to thread]:
runtime.cgocall(0x4002630, 0xc82003bcc8, 0x0)
        /usr/local/Cellar/go/1.5.1/libexec/src/runtime/cgocall.go:120 +0x11b fp=0xc82003bc98 sp=0xc82003bc68
_/Users/jls/projects/goczmq._Cfunc_zsocket_set_curve_secretkey_bin(0x680a200, 0x5202660)
        _/Users/jls/projects/goczmq/_test/_obj_test/_cgo_gotypes.go:1852 +0x31 fp=0xc82003bcc8 sp=0xc82003bc98
_/Users/jls/projects/goczmq.(*Cert).Apply(0xc82002c0f8, 0xc820013a40)
        /Users/jls/projects/goczmq/cert.go:94 +0x57 fp=0xc82003bce8 sp=0xc82003bcc8
_/Users/jls/projects/goczmq.TestAuthCurveAllowAny(0xc82007c5a0)
        /Users/jls/projects/goczmq/auth_test.go:201 +0x244 fp=0xc82003bf68 sp=0xc82003bce8
testing.tRunner(0xc82007c5a0, 0x4314f50)
        /usr/local/Cellar/go/1.5.1/libexec/src/testing/testing.go:456 +0x98 fp=0xc82003bfa0 sp=0xc82003bf68
runtime.goexit()
        /usr/local/Cellar/go/1.5.1/libexec/src/runtime/asm_amd64.s:1696 +0x1 fp=0xc82003bfa8 sp=0xc82003bfa0
created by testing.RunTests
        /usr/local/Cellar/go/1.5.1/libexec/src/testing/testing.go:561 +0x86d

Sometimes, go test will stacktrace (very rarely)

panic: close of closed channel

goroutine 4 [running]:
github.com/zeromq/goczmq.func·001(0xc2080286c0)
/home/luna/src/delta-go-workspace/src/github.com/zeromq/goczmq/channeler.go:54 +0x2c

goroutine 1 [chan receive]:
testing.RunTests(0x5d2e60, 0x84e7e0, 0x3f, 0x3f, 0xf12e18507a1cb101)
/usr/lib/go/src/testing/testing.go:556 +0xad6
testing.(*M).Run(0xc20802c0a0, 0x869280)
/usr/lib/go/src/testing/testing.go:485 +0x6c
main.main()
github.com/zeromq/goczmq/_test/_testmain.go:176 +0x1d5

goroutine 64 [syscall, locked to thread]:
github.com/zeromq/goczmq.Cfunc_zsock_destroy(0xc208038450, 0x7f3190002240, 0x97)
github.com/zeromq/goczmq/_test/_obj_test/_cgo_gotypes.go:339 +0x45
github.com/zeromq/goczmq.(*Sock).Destroy(0xc208038450)
/home/luna/src/delta-go-workspace/src/github.com/zeromq/goczmq/sock.go:341 +0x61
github.com/zeromq/goczmq.TestREQREP(0xc20808a000)
/home/luna/src/delta-go-workspace/src/github.com/zeromq/goczmq/sock_test.go:232 +0xaf3
testing.tRunner(0xc20808a000, 0x84ed08)
/usr/lib/go/src/testing/testing.go:447 +0xbf
created by testing.RunTests
/usr/lib/go/src/testing/testing.go:555 +0xa8b

goroutine 17 [syscall, locked to thread]:
runtime.goexit()
/usr/lib/go/src/runtime/asm_amd64.s:2232 +0x1
exit status 2
FAIL github.com/zeromq/goczmq 0.757s

Problem: "restrict" field in sockopts.xml is not honored

Some options only work with some socket types. sockopts.xml has a "restrict type" tag that denotes this. Currently, zsock_option.gsl does not use this tag.