erickt / rust-zmq

Rust zeromq bindings.

Rust ZeroMQ bindings.

Documentation

Release Notes

About

The zmq crate provides bindings for the libzmq library from the ZeroMQ project. The API exposed by zmq should be safe (in the usual Rust sense), but it follows the C API closely, so it is not very idiomatic.

Compatibility

The aim of this project is to track latest zmq releases as close as possible.

Regarding the minimum Rust version required, zmq is CI-tested on current stable channels of Rust.

Usage

zmq is a pretty straight forward port of the C API into Rust:

fn main() {
    let ctx = zmq::Context::new();

    let socket = ctx.socket(zmq::REQ).unwrap();
    socket.connect("tcp://127.0.0.1:1234").unwrap();
    socket.send("hello world!", 0).unwrap();
}

You can find more usage examples in https://github.com/erickt/rust-zmq/tree/master/examples.

Contributing

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in the work by you, as defined in the Apache-2.0 license, shall be dual licensed under the terms of both the Apache License, Version 2.0 and the MIT license without any additional terms or conditions.

See the contribution guidelines for what to watch out for when submitting a pull request.

rust-zmq's Issues

Usage example crashes on OS X

When I:

1. Create a new cargo project with cargo new zmqpipe --bin
2. Copy the usage example from the README.md to the single source file
3. Fix the compile time errors (rustc complains about the e.to_str() calls that get fed to the panic! macro, so I changed it to panic!(e))
4. Run the project with cargo run

Then the program compiles but somewhere in the socket.send_str function call the program just dies:

cargo clean && cargo run --verbose
Compiling gcc v0.3.5
Running rustc /Users/j/.cargo/registry/src/github.com-1ecc6299db9ec823/gcc-0.3.5/src/lib.rs --crate-name gcc --crate-type lib -g -C metadata=982b24959a427c6e -C extra-filename=-982b24959a427c6e --out-dir /Users/j/Development/rust/zmqpipe/target/debug/deps --emit=dep-info,link -L dependency=/Users/j/Development/rust/zmqpipe/target/debug/deps -L dependency=/Users/j/Development/rust/zmqpipe/target/debug/deps -Awarnings
Compiling libc v0.1.8
Running rustc /Users/j/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.1.8/rust/src/liblibc/lib.rs --crate-name libc --crate-type lib -g --cfg feature="cargo-build" --cfg feature="default" -C metadata=2eda841eb12a3090 -C extra-filename=-2eda841eb12a3090 --out-dir /Users/j/Development/rust/zmqpipe/target/debug/deps --emit=dep-info,link -L dependency=/Users/j/Development/rust/zmqpipe/target/debug/deps -L dependency=/Users/j/Development/rust/zmqpipe/target/debug/deps -Awarnings
Compiling rand v0.3.8
Running rustc /Users/j/.cargo/registry/src/github.com-1ecc6299db9ec823/rand-0.3.8/src/lib.rs --crate-name rand --crate-type lib -g -C metadata=b924d9fc5b3eb5b8 -C extra-filename=-b924d9fc5b3eb5b8 --out-dir /Users/j/Development/rust/zmqpipe/target/debug/deps --emit=dep-info,link -L dependency=/Users/j/Development/rust/zmqpipe/target/debug/deps -L dependency=/Users/j/Development/rust/zmqpipe/target/debug/deps --extern libc=/Users/j/Development/rust/zmqpipe/target/debug/deps/liblibc-2eda841eb12a3090.rlib -Awarnings
Compiling zmq-sys v0.6.6
Running rustc /Users/j/.cargo/registry/src/github.com-1ecc6299db9ec823/zmq-sys-0.6.6/src/lib.rs --crate-name zmq_sys --crate-type lib -g -C metadata=ffe3e0bd9933a05a -C extra-filename=-ffe3e0bd9933a05a --out-dir /Users/j/Development/rust/zmqpipe/target/debug/deps --emit=dep-info,link -L dependency=/Users/j/Development/rust/zmqpipe/target/debug/deps -L dependency=/Users/j/Development/rust/zmqpipe/target/debug/deps --extern libc=/Users/j/Development/rust/zmqpipe/target/debug/deps/liblibc-2eda841eb12a3090.rlib -Awarnings
Compiling log v0.3.1
Running rustc /Users/j/.cargo/registry/src/github.com-1ecc6299db9ec823/log-0.3.1/src/lib.rs --crate-name log --crate-type lib -g -C metadata=54cf393d3c69686f -C extra-filename=-54cf393d3c69686f --out-dir /Users/j/Development/rust/zmqpipe/target/debug/deps --emit=dep-info,link -L dependency=/Users/j/Development/rust/zmqpipe/target/debug/deps -L dependency=/Users/j/Development/rust/zmqpipe/target/debug/deps --extern libc=/Users/j/Development/rust/zmqpipe/target/debug/deps/liblibc-2eda841eb12a3090.rlib -Awarnings
Compiling time v0.1.25
Running rustc /Users/j/.cargo/registry/src/github.com-1ecc6299db9ec823/time-0.1.25/build.rs --crate-name build_script_build --crate-type bin -C prefer-dynamic -g --out-dir /Users/j/Development/rust/zmqpipe/target/debug/build/time-e758cbe877e9589d --emit=dep-info,link -L dependency=/Users/j/Development/rust/zmqpipe/target/debug/deps -L dependency=/Users/j/Development/rust/zmqpipe/target/debug/deps --extern gcc=/Users/j/Development/rust/zmqpipe/target/debug/deps/libgcc-982b24959a427c6e.rlib -Awarnings
Running /Users/j/Development/rust/zmqpipe/target/debug/build/time-e758cbe877e9589d/build-script-build
Running rustc /Users/j/.cargo/registry/src/github.com-1ecc6299db9ec823/time-0.1.25/src/lib.rs --crate-name time --crate-type lib -g -C metadata=e758cbe877e9589d -C extra-filename=-e758cbe877e9589d --out-dir /Users/j/Development/rust/zmqpipe/target/debug/deps --emit=dep-info,link -L dependency=/Users/j/Development/rust/zmqpipe/target/debug/deps -L dependency=/Users/j/Development/rust/zmqpipe/target/debug/deps --extern libc=/Users/j/Development/rust/zmqpipe/target/debug/deps/liblibc-2eda841eb12a3090.rlib -Awarnings -L native=/Users/j/Development/rust/zmqpipe/target/debug/build/time-e758cbe877e9589d/out -l static=time_helpers
Compiling zmq v0.6.7 (https://github.com/erickt/rust-zmq.git#8dd15146)
Running rustc /Users/j/.cargo/git/checkouts/rust-zmq-15b9a86635282bfd/master/src/lib.rs --crate-name zmq --crate-type lib -g -C metadata=0ca742aa10c064fb -C extra-filename=-0ca742aa10c064fb --out-dir /Users/j/Development/rust/zmqpipe/target/debug/deps --emit=dep-info,link -L dependency=/Users/j/Development/rust/zmqpipe/target/debug/deps -L dependency=/Users/j/Development/rust/zmqpipe/target/debug/deps --extern time=/Users/j/Development/rust/zmqpipe/target/debug/deps/libtime-e758cbe877e9589d.rlib --extern rand=/Users/j/Development/rust/zmqpipe/target/debug/deps/librand-b924d9fc5b3eb5b8.rlib --extern zmq_sys=/Users/j/Development/rust/zmqpipe/target/debug/deps/libzmq_sys-ffe3e0bd9933a05a.rlib --extern log=/Users/j/Development/rust/zmqpipe/target/debug/deps/liblog-54cf393d3c69686f.rlib --extern libc=/Users/j/Development/rust/zmqpipe/target/debug/deps/liblibc-2eda841eb12a3090.rlib -Awarnings -L native=/Users/j/Development/rust/zmqpipe/target/debug/build/time-e758cbe877e9589d/out
Compiling zmqpipe v0.1.0 (file:///Users/j/Development/rust/zmqpipe)
Running rustc src/main.rs --crate-name zmqpipe --crate-type bin -g --out-dir /Users/j/Development/rust/zmqpipe/target/debug --emit=dep-info,link -L dependency=/Users/j/Development/rust/zmqpipe/target/debug -L dependency=/Users/j/Development/rust/zmqpipe/target/debug/deps --extern zmq=/Users/j/Development/rust/zmqpipe/target/debug/deps/libzmq-0ca742aa10c064fb.rlib -L native=/Users/j/Development/rust/zmqpipe/target/debug/build/time-e758cbe877e9589d/out
Running target/debug/zmqpipe
Process didn't exit successfully: target/debug/zmqpipe (signal: 4)

Then, when I:

1. Debug it with lldb target/debug/zmqpipe
2. Put a breakpoint at line 16
3. Run the code
4. And finally, continue, then I get:

(lldb) c
Process 42444 resuming
Process 42444 stopped
\ * thread #1: tid = 0xe7dd05, 0x0000000100006987 zmqpipezmq::Message::from_slice(data=(data_ptr = <read memory from 0x650cff5fbff4e8 failed (0 of 8 bytes read)>, length = <read memory from 0x650cff5fbff4f0 failed (0 of 8 bytes read)>)) + 151 at lib.rs:637, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION (code=12, subcode=0x0) frame \#0: 0x0000000100006987 zmqpipezmq::Message::from_slice(data=(data_ptr = <read memory from 0x650cff5fbff4e8 failed (0 of 8 bytes read)>, length = <read memory from 0x650cff5fbff4f0 failed (0 of 8 bytes read)>)) + 151 at lib.rs:637
634 /// Create a Message from a &[u8]. This will copy data into the message.
635 pub fn from_slice(data: &[u8]) -> Result<Message, Error> {
636 unsafe {
-> 637 let mut msg = try!(Message::with_capacity_unallocated(data.len()));
638 ptr::copy_nonoverlapping(data.as_ptr(), msg.as_mut_ptr(), data.len());
639 Ok(msg)
640 }
(lldb)

Which indicates the issue is in rust-zmq somewhere. Any idea what might be wrong in the code?

Take advantage of "zero-copy" techniques from zmq blog

See http://zeromq.org/blog:zero-copy. This may also make the Sendable trait and wrapping zmq_send_const (see #119) unnecessary, as it should be possible to provide more efficient implementations of Into<Message> for &'static [u8]. Even without specialization, we could provide an efficient implementation of From<Vec<u8>> for Message, i.e. one that moves data out of the vector and hands ownership over to zmq.

Before implementing this, it would be nice to add a basic micro-benchmark first as a baseline. Even better would be to transcribe a (hopefully) existing micro-benchmark employing "zero-copy", so Rust performance can be compared to C before and after implementing the optimization.

Don't return Result from Message construction

According to the manpages, the only error that can occur when creating a new Message is out-of-memory, but Rust policy is to panic in these cases.

This is another API incompability, therefore for 0.9?

Is this actually supposed to work?

I was trying to run the examples (compiled with my patch against the latest Rust) and they all failed for all sorts of reasons, e.g. seg fault. Are there any known issues that I can help to fix?

Question about mutability

Hi,

I wonder if accepting &mut self (I think they're called mutable receivers) on methods such as Socket::send() would make more sense than using &self. Wouldn't it adhere to the philosophy better? After all, zmq_msg_send does take a socket, not a const socket.

Installing with rustpkg

Hello,

I installed rust-zmq with rustpkg install github.com/erickt/rust-zmq. It installed to $HOME/.rust, but when I run rustc to compile example.rs I get some errors:

$  rustc -L /home/simao/.rust/build/x86_64-unknown-linux-gnu/github.com/erickt/rust-zmq example.rs 

error: linking with `cc` failed with code 1
note: cc arguments: -L/usr/lib/rust/rust-0.8/lib/rustc/x86_64-unknown-linux-gnu/lib -m64 -o example example.o -L/usr/lib/rust/rust-0.8/lib/rustc/x86_64-unknown-linux-gnu/lib -lstd-6c65cf4b443341b1-0.8 -L/usr/lib/rust/rust-0.8/lib/rustc/x86_64-unknown-linux-gnu/lib -lextra-a7c050cfd46b2c9a-0.8 -L/home/simao/.rust/build/x86_64-unknown-linux-gnu/github.com/erickt/rust-zmq -lzmq-2cbaa875f4cd9f40-0.4 -lzmq -lrustrt -lrt -lpthread -L/home/simao/.rust/build/x86_64-unknown-linux-gnu/github.com/erickt/rust-zmq -L/home/simao/rust/.rust -L/home/simao/rust -L/home/simao/.rust -lrt -ldl -lm -lmorestack -lrustrt -Wl,-rpath,$ORIGIN/../../../usr/lib/rust/rust-0.8/lib/rustc/x86_64-unknown-linux-gnu/lib -Wl,-rpath,$ORIGIN/../.rust/build/x86_64-unknown-linux-gnu/github.com/erickt/rust-zmq -Wl,-rpath,/usr/lib/rust/rust-0.8/lib/rustc/x86_64-unknown-linux-gnu/lib -Wl,-rpath,/home/simao/.rust/build/x86_64-unknown-linux-gnu/github.com/erickt/rust-zmq
note: /home/simao/.rust/build/x86_64-unknown-linux-gnu/github.com/erickt/rust-zmq/libzmq-2cbaa875f4cd9f40-0.4.so: undefined reference to `zmq_msg_send'
/home/simao/.rust/build/x86_64-unknown-linux-gnu/github.com/erickt/rust-zmq/libzmq-2cbaa875f4cd9f40-0.4.so: undefined reference to `zmq_msg_recv'
/home/simao/.rust/build/x86_64-unknown-linux-gnu/github.com/erickt/rust-zmq/libzmq-2cbaa875f4cd9f40-0.4.so: undefined reference to `zmq_ctx_destroy'
/home/simao/.rust/build/x86_64-unknown-linux-gnu/github.com/erickt/rust-zmq/libzmq-2cbaa875f4cd9f40-0.4.so: undefined reference to `zmq_ctx_new'
collect2: error: ld returned 1 exit status

error: aborting due to previous error

What am I doing wrong?

Thanks

Should Context::socket() be &self instead of &mut self?

So I understand that Context::socket() changes the state of the context, which is presumably the idea behind making it &mut self. That said, it's entirely safe for multiple threads to call socket() on the same context, so it should be safe to make it &self.

My motivation for suggesting this is that, right now, the suggested method for sharing a context between threads is to use an Arc pointer. But once you have the context in an Arc pointer, there doesn't seem to be a way to get a hold of a mutable pointer to it, so you can't make any more sockets. Arc::make_unique() is unavailable, since Context doesn't implement Clone, and that would do the wrong thing anyway.

Example (possibly the library?) broken

On Arch x86_64, rust 0.5 built from aur/rust package:

Code compiles, running example results in:

$ ./main       
version: 3 2 2
starting client
rust: task failed at 'Invalid argument', ./zmq.rc:537
rust: domain main @0x1cebc00 root task failed

This hints it breaks on https://github.com/erickt/rust-zmq/blob/master/example.rs#L25 as

io::println(fmt!("hwm: %?", socket.get_hwm().get()));

is never reached.

ZeroMQ version (as output states) is 3.2.2, rust is 0.5

Port to Rust 1.0.0 alpha

Is it possible to port rust-zmq to latest Rust?

Socket and PollItem should be Send

Both Socket and PollItem are safe to be Send (they are not automatically because they contain c_void * pointers, but this is fine since neither references any other data). Neither is allowed to be Sync, see the loud warning under "Thread Safety" in http://api.zeromq.org/3-2:zmq-socket

Creating context in scope hangs program when scope ends

The following minimal example hangs and blocks execution of the program; the message “Socket returned” is never printed. I suspect this is because the context gets destroyed at the end of the scope, while the socket built on top of that context still lives on. I guess doing this is a very bad idea; the fix consists in not having the context destroyed (as can be seeen by uncommenting/commenting the lines I have indicated). It would be great if this would throw some serious error message.

extern crate zmq;

fn main() {
    let address = Some("tcp://127.0.0.1:5556".to_string());
    // let mut context; // Uncomment to make it work;

    let mut publisher = match address.as_ref() {
        Some(address) => {
            println!("Setting up socket");

            let mut context = zmq::Context::new(); // Comment to make it work;
            // context = zmq::Context::new(); // Uncomment to make it work

            let mut publisher = context.socket(zmq::PUB).unwrap();
            assert!(publisher.bind(address).is_ok());

            println!("Returning socket");

            Some(publisher)
        }
        None => None
    };

    println!("Socket returned");

    let data: u8 = 1;

    loop {
        let s = format!("data {}", data);
        println!("Sending {}", s);
        publisher.as_mut().unwrap().send_str(&s, 0).unwrap();
    }
}

There is some possibility to develop encryption for messages exchanged in zmq.rs??

Compatibility for libzmq3 / older Debians?

Mostly an FYI issue, feel free to close right away.

I have had a crate depending on rust-zmq that has been running nicely on Debian jessie and wheezy for over a year now, and has built nicely with Travis with only adding:

addons:
  apt:
    packages:
      - libzmq3-dev

I decided to update to the latest master today, since I have been tracking the github repo, and sadly the comfy travis config is no longer supported, and neither are my old-fashioned Debian servers. Clearly updating to a 4.* libzmq from source would be one way out, but that's something I'd like to postpone as much as possible, extra complexity in setup and all.

Long story short, I wanted to share my updated Cargo.toml dependency which still works on legacy systems, I simply copied the last revision sha that was operational on Travis for me:

[dependencies.zmq]
git = "https://github.com/erickt/rust-zmq.git"
rev = "87a6bd2a7ce09200b6f0a5bdc08ef684c4951f21"

Since the crate is updated on crates.io somewhat rarely, I'll freeze the revision until an upgrade happens somewhere: OS upgrade on the servers, or added backwards compatibility to rust-zmq. Just a tip that may keep other rust-zmq users happy until the world moves forward.

No Makefile

$ more README
To build, just run make.
$ make
make: *** No targets specified and no makefile found. Stop.

Improve genericity for `recv`

It should be possible to achieve enhanced genericity for recv, as we now have From and Into implementations for Message due to PR #130.

Will zeromq V2 be supported?

I have a legacy project which needs to use zeromq 2.1.7. Is it possible to support V2 ?

Doesn't compile on Windows

Those error codes are only meaningful under *nix. Latest libc does not define them on Win.

src\lib.rs:126:23: 126:35 error: unresolved name libc::EACCES [E0425]
src\lib.rs:126 EACCES = libc::EACCES as isize,
^~~~~~~~~~~~
src\lib.rs:126:23: 126:35 help: run rustc --explain E0425 to see a detailed ex planation
src\lib.rs:127:23: 127:39 error: unresolved name libc::EADDRINUSE [E0425]
src\lib.rs:127 EADDRINUSE = libc::EADDRINUSE as isize,
^~~~~~~~~~~~~~~~
src\lib.rs:127:23: 127:39 help: run rustc --explain E0425 to see a detailed ex planation
src\lib.rs:128:23: 128:35 error: unresolved name libc::EAGAIN [E0425]
src\lib.rs:128 EAGAIN = libc::EAGAIN as isize,
^~~~~~~~~~~~
src\lib.rs:128:23: 128:35 help: run rustc --explain E0425 to see a detailed ex planation
src\lib.rs:129:23: 129:34 error: unresolved name libc::EBUSY [E0425]
src\lib.rs:129 EBUSY = libc::EBUSY as isize,
^~~~~~~~~~~
src\lib.rs:129:23: 129:34 help: run rustc --explain E0425 to see a detailed ex planation
src\lib.rs:130:23: 130:41 error: unresolved name libc::ECONNREFUSED [E0425]
src\lib.rs:130 ECONNREFUSED = libc::ECONNREFUSED as isize,
^~~~~~~~~~~~~~~~~~
src\lib.rs:130:23: 130:41 help: run rustc --explain E0425 to see a detailed ex planation
src\lib.rs:131:23: 131:35 error: unresolved name libc::EFAULT [E0425]
src\lib.rs:131 EFAULT = libc::EFAULT as isize,
^~~~~~~~~~~~
src\lib.rs:131:23: 131:35 help: run rustc --explain E0425 to see a detailed ex planation
src\lib.rs:132:23: 132:34 error: unresolved name libc::EINTR [E0425]
src\lib.rs:132 EINTR = libc::EINTR as isize,
^~~~~~~~~~~
src\lib.rs:132:23: 132:34 help: run rustc --explain E0425 to see a detailed ex planation
src\lib.rs:133:23: 133:41 error: unresolved name libc::EHOSTUNREACH [E0425]
src\lib.rs:133 EHOSTUNREACH = libc::EHOSTUNREACH as isize,
^~~~~~~~~~~~~~~~~~
src\lib.rs:133:23: 133:41 help: run rustc --explain E0425 to see a detailed ex planation
src\lib.rs:134:23: 134:40 error: unresolved name libc::EINPROGRESS [E0425]
src\lib.rs:134 EINPROGRESS = libc::EINPROGRESS as isize,
^~~~~~~~~~~~~~~~~
src\lib.rs:134:23: 134:40 help: run rustc --explain E0425 to see a detailed ex planation
src\lib.rs:135:23: 135:35 error: unresolved name libc::EINVAL [E0425]
src\lib.rs:135 EINVAL = libc::EINVAL as isize,
^~~~~~~~~~~~
src\lib.rs:135:23: 135:35 help: run rustc --explain E0425 to see a detailed ex planation
src\lib.rs:136:23: 136:35 error: unresolved name libc::EMFILE [E0425]
src\lib.rs:136 EMFILE = libc::EMFILE as isize,
^~~~~~~~~~~~
src\lib.rs:136:23: 136:35 help: run rustc --explain E0425 to see a detailed ex planation
src\lib.rs:137:23: 137:37 error: unresolved name libc::EMSGSIZE [E0425]
src\lib.rs:137 EMSGSIZE = libc::EMSGSIZE as isize,
^~~~~~~~~~~~~~
src\lib.rs:137:23: 137:37 help: run rustc --explain E0425 to see a detailed ex planation
src\lib.rs:138:23: 138:41 error: unresolved name libc::ENAMETOOLONG [E0425]
src\lib.rs:138 ENAMETOOLONG = libc::ENAMETOOLONG as isize,
^~~~~~~~~~~~~~~~~~
src\lib.rs:138:23: 138:41 help: run rustc --explain E0425 to see a detailed ex planation
src\lib.rs:139:23: 139:35 error: unresolved name libc::ENODEV [E0425]
src\lib.rs:139 ENODEV = libc::ENODEV as isize,
^~~~~~~~~~~~
src\lib.rs:139:23: 139:35 help: run rustc --explain E0425 to see a detailed ex planation
src\lib.rs:140:23: 140:35 error: unresolved name libc::ENOENT [E0425]
src\lib.rs:140 ENOENT = libc::ENOENT as isize,
^~~~~~~~~~~~
src\lib.rs:140:23: 140:35 help: run rustc --explain E0425 to see a detailed ex planation
src\lib.rs:141:23: 141:35 error: unresolved name libc::ENOMEM [E0425]
src\lib.rs:141 ENOMEM = libc::ENOMEM as isize,
^~~~~~~~~~~~
src\lib.rs:141:23: 141:35 help: run rustc --explain E0425 to see a detailed ex planation
src\lib.rs:142:23: 142:37 error: unresolved name libc::ENOTCONN [E0425]
src\lib.rs:142 ENOTCONN = libc::ENOTCONN as isize,
^~~~~~~~~~~~~~
src\lib.rs:142:23: 142:37 help: run rustc --explain E0425 to see a detailed ex planation
src\lib.rs:143:23: 143:37 error: unresolved name libc::ENOTSOCK [E0425]
src\lib.rs:143 ENOTSOCK = libc::ENOTSOCK as isize,
^~~~~~~~~~~~~~
src\lib.rs:143:23: 143:37 help: run rustc --explain E0425 to see a detailed ex planation
src\lib.rs:144:23: 144:35 error: unresolved name libc::EPROTO [E0425]
src\lib.rs:144 EPROTO = libc::EPROTO as isize,
^~~~~~~~~~~~
src\lib.rs:144:23: 144:35 help: run rustc --explain E0425 to see a detailed ex planation
src\lib.rs:145:23: 145:44 error: unresolved name libc::EPROTONOSUPPORT [E0425]
src\lib.rs:145 EPROTONOSUPPORT = libc::EPROTONOSUPPORT as isize,
^~~~~~~~~~~~~~~~~~~~~
src\lib.rs:145:23: 145:44 help: run rustc --explain E0425 to see a detailed ex planation

recv_string() does not handle non-UTF8 data correctly

Since revision 91aaf3c ("fix for nightly"), non-UTF8 data is not returned as an inner Err(Vec<u8>), but you'll always get Ok(""). (Fix incoming.)

`Error` should be convertible into `std::io::Error`

The subset of error conditions that are directly representable can be mirrored, the others can be represented as ErrorKind::Other.

Support for `ZMQ_LAST_ENDPOINT` socket option getter

This is required to support ephemeral ports; it would probably make sense to have some convenience API for parsing the ZMQ endpoint address string.

Make socket options generic

As hinted in the discussion of #103, it would be possible to improve the socket option API, such that it becomes possible to write code that is generic over the socket options. For example functions like these should be implementable:

fn show_option<O>(sock: &Socket, option: O) -> String
    where O: sockopt::Readable, O::Item: Debug;
fn set_option<O>(sock: &Socket, option: O, s: &str)
    where O: sockopt:Writable, O::Item: FromStr;

PollItems should have a way to get back their sockets

Right now PollItems are frustrating to use because once you know there is data to be read, there is no mechanism to actually read said data (unless you remember the mapping between PollItems and Sockets).

It is possible to write a one-liner function that pulls the sock member out of a PollItem and into a Socket.

Add and improve documentation

We should try to give a rough overview of the API offered, and especially highlight the differences from the C API.

Track down Windows/Appveyor test failures

We managed to get our zeromq tests partially passing on Windows, but we still need some help tracking down why 5 of our tests are timing out. We need this before we can say we officially support Windows. @tcosprojects / @pfernie / @Ginurx, you've all opened tickets/pull requests to get this crate to work on Windows, any chance you could help us track down what's going on in these tests?

doesnt compile on mac

After a fresh checkout on master (rev: 5cd311a6127a7dd49920cc0a3f7f9501b155146c):

$ rustup run stable cargo build
   Compiling log v0.3.6
   Compiling libc v0.2.17
   Compiling zmq v0.8.0 (file:///Users/crawford/git/rust-zmq)
   Compiling pkg-config v0.3.8
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-m64" "-L" "/Users/crawford/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "/Users/crawford/git/rust-zmq/target/debug/build/zmq-f1af77045cea9564/build_script_build.0.o" "-o" "/Users/crawford/git/rust-zmq/target/debug/build/zmq-f1af77045cea9564/build_script_build" "-Wl,-dead_strip" "-nodefaultlibs" "-L" "/Users/crawford/git/rust-zmq/target/debug/deps" "-L" "/Users/crawford/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib" "-l" "zmq" "/Users/crawford/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-40393716.rlib" "/Users/crawford/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libpanic_unwind-40393716.rlib" "/Users/crawford/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libunwind-40393716.rlib" "/Users/crawford/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librand-40393716.rlib" "/Users/crawford/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcollections-40393716.rlib" "/Users/crawford/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librustc_unicode-40393716.rlib" "/Users/crawford/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc-40393716.rlib" "/Users/crawford/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-40393716.rlib" "/Users/crawford/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liblibc-40393716.rlib" "/Users/crawford/.multirust/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcore-40393716.rlib" "-l" "System" "-l" "pthread" "-l" "c" "-l" "m" "-l" "compiler-rt"
  = note: Undefined symbols for architecture x86_64:
  "_zmq_has", referenced from:
      build_script_build::main::h7e8d72e8cd20ab74 in build_script_build.0.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)


error: aborting due to previous error

Getting data from C++ program

I have a server sending data using ZMQ writed in C++ and a want to retrieve this data using a program writed in Rust. I'm trying to adapt the https://github.com/erickt/rust-zmq/blob/master/examples/zguide/weather_client/main.rs but without success. It's a simple problem, may you help me?

Here is the code used to create the server in C++

context = new zmq::context_t(1);
socket = new zmq::socket_t(*context, ZMQ_PUB);
socket->bind(addr_server_multicast.c_str());

Here is the code used in the server to send the data

zmq::message_t request (msg_str.size());
memcpy ((void *) request.data (), msg_str.c_str(), msg_str.size());
socket->send(request);**

Here is the code used to create the client in C++, which I want to write in Rust

context = new zmq::context_t(1);
socket = new zmq::socket_t(*context, ZMQ_SUB);
socket->connect(addr_client_multicast.c_str());
socket->setsockopt(ZMQ_SUBSCRIBE, "", 0);

Here is the code used in the client to get the data

zmq::message_t request;
socket->recv(&request, 0); //  Wait for next request from client
std::string msg_str(static_cast<char*>(request.data()), request.size());

Here is the code which I trying the retrieve the data in Rust

let mut context = zmq::Context::new();
let mut subscriber = context.socket(zmq::SUB).unwrap();
assert!(subscriber.connect("tcp://localhost:5555").is_ok());

let filter = "10001".to_string();
assert!(subscriber.set_subscribe(filter.as_bytes()).is_ok());

loop {
    println!("reading");
    let string = subscriber.recv_string(0).unwrap().unwrap();
    println!("readed");
}

The rust program stops after print reading.

Verify destructor order is correct

I'm very suspicious about the order that destructors are called. zmq_ctx_destroy will hang is the destructors of the sockets haven't been called first.

recv_into needs to return number of bytes written

Another API change: if recv_into does not return a usize with the number of bytes in the message, it is not very useful.

Macro Trouble Compiling?

When trying to build I am getting this error (repeated 20 times, though it says something about there being "42 previous errors"):

src/lib.rs:27:20: 27:23 error: expected expression, found unsafe
src/lib.rs:27 let rc = $($tt)*;
^~~

(That ^ should be pointing at the $tt, but I couldn't figure out how to format that spacing...)

Suggestions? I am at d473b20, maybe backup to an earlier commit?

Thanks,

-kb

Why &str instead of String?

This is probably my ignorance, but why are you using a str ref for methods like socket.connect instead of String? I normally derive my connection strings from a static protocol and a variable endpoint address, e.g. "ipc://" + addr. As far as I'm aware, you can't concatenate two static strings and end up with a static string. And as String.to_str() is not yet stable, wouldn't it make sense to be able to pass a String object instead of a &str?

With the current implementation, how would you implement something like this:

let conn = format!("ipc://{}", socket_path);
socket.connect(conn).unwrap();

Ta!

Register with Travis CI

See http://hiho.io/rust-ci/

Necessary steps: http://hiho.io/rust-ci/help/

Integrate with Rust event loop

This task deadlocking issue was firstly raised here:

https://mail.mozilla.org/pipermail/rust-dev/2013-November/006365.html

where @erickt suggested that

Or perhaps there is some way we
can feed the ZMQ_FD of a socket to libuv to protect against task
deadlocking.

It was not quite possible back in 2012:

http://lists.zeromq.org/pipermail/zeromq-dev/2012-March/016561.html

But it seems doable now in 2014:

https://github.com/joyent/libuv/blob/master/include/uv.h#L1164

* The uv_poll watcher is used to watch file descriptors for readability and
* writability, similar to the purpose of poll(2).
*
* The purpose of uv_poll is to enable integrating external libraries that
* rely on the event loop to signal it about the socket status changes, like
* c-ares or libssh2.

And it seems people are already doing so:

https://github.com/benoitc/uzmq/blob/master/uzmq/sock.py#L41

Notably, rust-lang/rust#11410 is introducing the uv_poll_t features.

Construct Socket struct from raw pointer

I have a Rust library that is consumed by a C program. Several Rust functions take a ZMQ socket as an arg, which I want to pass through from my C program. While I can pass a raw pointer to a socket, I can't construct a new Socket struct as its parameters are private.

Could a new function be implemented on the Socket struct, called from_raw or something, that would allow me to create a new Socket from this raw pointer? Alternatively Socket could implement the convert::From trait to do the same thing.

I'm happy to create a PR for this, but what do you guys think?

Replace `send` and `recv` flags with a more type-safe API

Currently send/recv functions just take them as an int and there are no defines.

At the very least there should be static definitions. But would probably be better as a proper 'Flag' type (enum?).

Fails to build on docs.rs

See https://docs.rs/crate/zmq/0.8.0/builds/35973. We probably need to allow for cargo doc to be run without having libzmq installed, if possible.

Can PUB/SUB use topic filtering?

In the Node.js version of zmq, when publishing a message on a PUB socket you can set a topic and a message, and the SUB socket filters them by topic. However, when sending a message from a PUB socket using this crate, the first argument of .send is set as the topic and the message is blank. Is there a way to send a message body as well with this crate?

Incompatibility with zmq 4.x

The readme doesn't state the required libzmq version, so I was trying with 4.1.1. This appears to be binary incompatible with 3.x.

running helloworld_server example:

thread '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: Bad address', /var/tmp/portage/dev-lang/rust-999/work/rustc-nightly/src/libcore/result.rs:731
stack backtrace:
   1:     0x7f0d24732b53 - sys::backtrace::write::hcf068903b51cfe2bkds
   2:     0x7f0d24735df1 - panicking::on_panic::h417cbf9fca890635fWw
   3:     0x7f0d2472e8ea - rt::unwind::begin_unwind_inner::haa3e65fd351aaf75ZBw
   4:     0x7f0d2472ec07 - rt::unwind::begin_unwind_fmt::h6eccac85ccefdd175Aw
   5:     0x7f0d24735746 - rust_begin_unwind
   6:     0x7f0d2475bed4 - panicking::panic_fmt::h6bb5eab6a35b4ca8i5B
   7:     0x7f0d2472bea0 - main::h3104d7f3d30ba747gaa
   8:     0x7f0d2473a428 - rust_try_inner
   9:     0x7f0d2473a415 - rust_try
  10:     0x7f0d24737593 - rt::lang_start::h3197185c34da9942jRw
  11:     0x7f0d23f18f9f - __libc_start_main
  12:     0x7f0d2472bad8 - <unknown>
  13:                0x0 - <unknown>
thread '<main>' panicked at 'assertion failed: `(left == right)` (left: `-1`, right: `0`)', src/lib.rs:597
stack backtrace:
   1:     0x7f0d24732b53 - sys::backtrace::write::hcf068903b51cfe2bkds
   2:     0x7f0d24735df1 - panicking::on_panic::h417cbf9fca890635fWw
   3:     0x7f0d2472e8ea - rt::unwind::begin_unwind_inner::haa3e65fd351aaf75ZBw
   4:     0x7f0d2472ec07 - rt::unwind::begin_unwind_fmt::h6eccac85ccefdd175Aw
   5:     0x7f0d2472d0d7 - Message.Drop::drop::h0b916bc8e49fb312h0a
   6:     0x7f0d2472bec1 - main::h3104d7f3d30ba747gaa
   7:     0x7f0d2473a428 - rust_try_inner
   8:     0x7f0d2473a415 - rust_try
   9:     0x7f0d24737593 - rt::lang_start::h3197185c34da9942jRw
  10:     0x7f0d23f18f9f - __libc_start_main
  11:     0x7f0d2472bad8 - <unknown>
  12:                0x0 - <unknown>
thread panicked while panicking. aborting.
An unknown error occurred

running helloworld_client example:

Connecting to hello world server...

Sending Hello 0
Assertion failed: check () (/var/tmp/portage/net-libs/zeromq-4.1.1/work/zeromq-4.1.1/src/msg.cpp:220)
An unknown error occurred

./zmq.rs:174:12: 174:15 error: expected `;` or `}` after expression but found

info: installing central/zmq via git...
./zmq.rs:174:12: 174:15 error: expected ; or } after expression but found err
./zmq.rs:174 ret err(errno_to_error());
^~~
rust: task failed at 'explicit failure', /media/debian-home/nadav/projects/rust/src/libsyntax/diagnostic.rs:52

Support for ZMQ_STREAM socket type

Is it planned to add support for ZMQ_STREAM sockets ?

http://api.zeromq.org/4-2:zmq-socket#toc17

Time for new release

It looks like several issues were fixed after the last release. Maybe bump the version and publish to crates.io?

rust-zmq does not build with nightly

src/zmq/lib.rs:30:13: 30:33 error: expected constant expr for vector length: non-constant path in constant expr
src/zmq/lib.rs:30 type Msg_ = [c_char, ..MsgSize_];
^~~~~~~~~~~~~~~~~~~~

Submitted pull request #46

Cargo Build Error: linking with `cc` failed:

I'm trying to compile an example using the rust-zmq, but I got this error everytime. If I run cargo build in the repository of rust-zmq the same error appears.

   Compiling protobuf v1.0.24
     Running `rustc /home/sirlab/.cargo/registry/src/github.com-88ac128001ac3a9a/protobuf-1.0.24/src/lib/protobuf.rs --crate-name protobuf --crate-type lib -g -C metadata=3657c58ea923a469 -C extra-filename=-3657c58ea923a469 --out-dir /home/sirlab/Repositorios/SIRLab/beta/Rust-Interface/target/debug/deps --emit=dep-info,link -L dependency=/home/sirlab/Repositorios/SIRLab/beta/Rust-Interface/target/debug/deps -L dependency=/home/sirlab/Repositorios/SIRLab/beta/Rust-Interface/target/debug/deps --cap-lints allow`
   Compiling zmq v0.8.0 (https://github.com/erickt/rust-zmq.git#5cd311a6)
     Running `rustc /home/sirlab/.cargo/git/checkouts/rust-zmq-d3f20ec7988b7dcb/master/build.rs --crate-name build_script_build --crate-type bin -g --out-dir /home/sirlab/Repositorios/SIRLab/beta/Rust-Interface/target/debug/build/zmq-7d3796e1996f3ce7 --emit=dep-info,link -L dependency=/home/sirlab/Repositorios/SIRLab/beta/Rust-Interface/target/debug/deps -L dependency=/home/sirlab/Repositorios/SIRLab/beta/Rust-Interface/target/debug/deps --cap-lints allow`
       Fresh libc v0.2.17
   Compiling log v0.3.6
     Running `rustc /home/sirlab/.cargo/registry/src/github.com-88ac128001ac3a9a/log-0.3.6/src/lib.rs --crate-name log --crate-type lib -g --cfg feature=\"use_std\" --cfg feature=\"default\" -C metadata=30a8a27ec161f1be -C extra-filename=-30a8a27ec161f1be --out-dir /home/sirlab/Repositorios/SIRLab/beta/Rust-Interface/target/debug/deps --emit=dep-info,link -L dependency=/home/sirlab/Repositorios/SIRLab/beta/Rust-Interface/target/debug/deps -L dependency=/home/sirlab/Repositorios/SIRLab/beta/Rust-Interface/target/debug/deps --cap-lints allow`
       Fresh pkg-config v0.3.8
   Compiling zmq-sys v0.8.0 (https://github.com/erickt/rust-zmq.git#5cd311a6)
     Running `rustc /home/sirlab/.cargo/git/checkouts/rust-zmq-d3f20ec7988b7dcb/master/zmq-sys/build.rs --crate-name build_script_build --crate-type bin -g --out-dir /home/sirlab/Repositorios/SIRLab/beta/Rust-Interface/target/debug/build/zmq-sys-689e3244aaf14c79 --emit=dep-info,link -L dependency=/home/sirlab/Repositorios/SIRLab/beta/Rust-Interface/target/debug/deps -L dependency=/home/sirlab/Repositorios/SIRLab/beta/Rust-Interface/target/debug/deps --extern pkg_config=/home/sirlab/Repositorios/SIRLab/beta/Rust-Interface/target/debug/deps/libpkg_config-4db00a0f261b88d6.rlib --cap-lints allow`
     Running `/home/sirlab/Repositorios/SIRLab/beta/Rust-Interface/target/debug/build/zmq-sys-689e3244aaf14c79/build-script-build`
error: linking with `cc` failed: exit code: 1
note: "cc" "-Wl,--as-needed" "-m64" "-L" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/sirlab/Repositorios/SIRLab/beta/Rust-Interface/target/debug/build/zmq-7d3796e1996f3ce7/build_script_build.0.o" "-o" "/home/sirlab/Repositorios/SIRLab/beta/Rust-Interface/target/debug/build/zmq-7d3796e1996f3ce7/build_script_build" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" "/home/sirlab/Repositorios/SIRLab/beta/Rust-Interface/target/debug/deps" "-L" "/home/sirlab/Repositorios/SIRLab/beta/Rust-Interface/target/debug/deps" "-L" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "-l" "zmq" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-6a154fe0.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-6a154fe0.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_unicode-6a154fe0.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-6a154fe0.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-6a154fe0.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-6a154fe0.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-6a154fe0.rlib" "/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-6a154fe0.rlib" "-l" "dl" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "compiler-rt"
note: /home/sirlab/Repositorios/SIRLab/beta/Rust-Interface/target/debug/build/zmq-7d3796e1996f3ce7/build_script_build.0.o: na função `build_script_build::main':
/home/sirlab/.cargo/git/checkouts/rust-zmq-d3f20ec7988b7dcb/master/build.rs:6: referência indefinida para `zmq_has'
collect2: error: ld returned 1 exit status

error: aborting due to previous error
Build failed, waiting for other jobs to finish...

Ubuntu 14.04
rustc 1.7.0 (a5d1e7a59 2016-02-29)
cargo 0.8.0-nightly (28a0cbb 2016-01-17)

Curiously, the same code works well in another desktop which has Ubuntu 16.04.

Support for ZMQ_CLIENT and ZMQ_SERVER socket types missing

These have been added in libzmq 4.2 and constitute a considerable addition to the API, including:

• New routing_id attribute on zmq_msg_t.
• Multipart messages (zmq::SNDMORE) are not supported for these sockets
• ZMQ_CLIENT and ZMQ_SERVER sockets are thread-safe. This requires a new type for these socket types, so they can be made Sync, and that in turn may make backwards-incompatible changes to the existing API necessary.

Hangs when returning a zmq::Socket

See this code:
`
// http://pastebin.com/dCVLHa4a

extern crate zmq;

use std::io::Write;


fn write_sting_oke() {
    let topic_endpoint = "tcp://*:5556";

    let mut ctx = zmq::Context::new();
    let mut socket = match ctx.socket(zmq::PUB) {
      Ok(socket) => { socket },
      Err(e) => { panic!(e) }
    };

    // match socket.connect(&topic_endpoint) {
    //   Ok(()) => (),
    //   Err(e) => panic!(e)
    // };
    assert!(socket.bind(topic_endpoint).is_ok());
    
    let topic = "test";
    let message = "testing-oke-thing";
    let update = format!("{} {}", topic, message);
    socket.send(update.as_bytes(), 0).unwrap();
}

fn pub_socket() -> zmq::Socket {
    let topic_endpoint = "tcp://localhost:5556";

    let mut ctx = zmq::Context::new();
    let mut socket = match ctx.socket(zmq::PUB) {
      Ok(socket) => { socket },
      Err(e) => { panic!(e) }
    };

    match socket.connect(&topic_endpoint) {
      Ok(()) => (),
      Err(e) => panic!(e)
    };
    writeln!(std::io::stderr(), "return socket (will fail)").unwrap();
    socket
}

fn write_sting_fail() {
    writeln!(std::io::stderr(), "before pub_socket").unwrap();
    let mut socket = pub_socket();
    writeln!(std::io::stderr(), "after pub_socket").unwrap();

    let message = "test testing-fail-thing".as_bytes();

    match socket.send(message, 0) {
      Ok(()) => (),
      Err(e) => panic!(e)
    };
}

fn main() {
    println!("Hello World!");
    println!("Will do");
    write_sting_oke();
    println!("Will hang");
    write_sting_fail();
}

`
The function "pub_socket()" never returns and hangs.
I also created a gdb stacktrace: http://pastebin.com/BKpdJPUv

Is there

Does rust-zmq work on Windows?

Thanks 😄

Travis check broken

Currently, the Travis build is consistently broken on nightly. I briefly looked at it, and my guess sof far is that somehow their nightly rustc is broken; the linker error not finding libtest-<HASH> does not occur locally.

My next step would have been to identify a recent travis build of some other crates that works on nightly, and try to figure why they suceed when rust-zmq fails. The failed attempts of doing so can be inspected in the wip/travis branch of my rust-zmq fork.

Please comment on this issues if you have any ideas of how to resolve this, or can reproduce the build failure locally.

Wrap zmq_send_const?

ZMQ 4.2 has an API called zmq_send_const, which allows sending static data without having to be copied into a Message.

Do we want to support this special case (for &'static [u8] arguments)?

Missing zmq_msg_more wrapper

getsockopt() and setsockopt() wrapper method types

I'd like to discuss the types of several socket option accessors, which I think could be improved, although that would introduce API breakage:

1. get_curve_{publickey,secretkey,serverkey} have an overly complicated return type. As the C API should guarantees that the returned string representation is valid Z85-encoded data, and, by extension, valid ASCII and hence UTF-8, we could panic if the C API violates that guarantee, and hence return Result<String> instead of Result<result::Result<String, Vec<u8>>>.

2. All the accessors handling (potentially) Z85-encoded data (including the getters mentioned above) are currently tuned toward Z85 string representation, while the binary variant exposed by the C API is not exposed.

   For the setters, the API exposed even is "ambiguous": If you pass in a 40-byte &str libzmq will treat that as Z85 data, as (probably) intended. If you happen to pass in a 32-byte &str, perhaps originating from user input, libzmq will happily accept that as binary data. I think this is non-obvious, and has potential for inducing bugs.

   I propose changing all these functions to only expose the binary variant of the C API, and having the user explicitly decode/encode Z85 strings if needed. Methods accepting/returning string data could be added as second variant (for instance suffixed with _z85).

I'd like to hear some opinions on that; if I get positive feedback, I will try to come up with a PR.

Document get_endpoint windows behavior

@pfernie found in #140 that get_endpoint has different behavior on windows than on unix systems. It doesn't appear to like tcp:*:* and upstream swaps it with tcp://127.0.0.1:*. We should document this.