We should add some criterion benchmark to test performance per socket type. The benchmarks results should be in throughput per second and should be displayed in a file somewhere.

We should consider inlining the hot path based on benchmarks. Parts to consider:

• send calls
• recv calls
• Msg creation / convertion
• Poller method calls

See zmq_proxy. I do not know at this time if the draft socket types are supported by the proxy.

Blocked until async await stabilization.

When a connection succeeds the socket is no longer in mute state and can queue outgoing messages via send. The problem is if the authentication failed the user will never know it: he has effectively no way of knowing if his credentials were misconfigured. Here is the issue I filled zeromq/libzmq#3505.

zeromq/libzmq#3523

Currently PgmAddr is only a wrapper around String. Using the same interface (if possible), proper parsing (FromStr trait) and appropriate methods should be implemented.

See zmq_pgm for reference.

The is no specific reason for the cloning atm aside from the convenience.

This would be the inproc equivalent of a system assigned port.

Currently to do unit testing in the API we create a ton of Ctx so that we don't name clash with other unit tests. We could instead add a method to InproAddr that generates a unique inproc address and use the global context. This would also improve documentation as a side effect since users won't be tempted tu created a Ctx unnecessarily from reading the doc.

Performance using CURVE is horrendous. Not sure if this is a recent regression.

When looking at the callgraph i get that most of the overhead is cause by:
69.15% 69.00% ZMQbg/IO/0 writer [.] crypto_onetimeauth
which is a fcn that should only occur when the handshake occurs. So something is wrong.

• Add changes to CHANGELOG.md
• Add doc & test
• Commit message format (problem & solution?)
• Cargo fmt & clippy
• Etc.

Since we are relying of c / c++ code we should fuzz the socket inputs / outputs. We should probably use something like afl. Then we should file issues with our findings (if any) to the libzmq project.

We could feature gate the bindgen generation. This would remove the dependency on clang. Only maintainers would need to enable this feature to update the bindings once in a while.

If there is no performance difference, we should make recv_msg the only API.

Currently there is no support for the ipc transport. We should resolve that.

We should implement this book via mdBook and host it directly in github pages.

We should implement a timer API similar tokio timer. This would allow use to schedule timeouts and intervals using the libzmq event loop.

Here is the general design I had in mind.

• Create a Server in a thread (global singleton?). This server will be in charge of keeping track of all the Interval and sending notification to the client.
• Create a Client thread an connect it to the server.
• Send a request for scheduling an Interval with a specific id to the server.
• The sever will send reply messages with the specified id at the specified interval.
• There can be many Client thread connected to the Server thread at the same time.

We should provide for some channel patterns that can send Box allocated arbitrary types for inter thread communication.

Each socket has an associated configuration struct that can be use to parse config files. We should document the config file format.

Since Poller now supports any type that implements AsRawFd, this mean we could be polling all sorts of things. There are platform specific event flags that are currently not supported by the bitflag which causes a crash at poll.rs:185. We should conditionally define these flags per platform.

The might be an opportunity to share the sys crate with erickt/rust-zmq#257. However we would have to make sure to use the master branch and support the draft API.

See #95.

This would close #96 .

Current heartbeat API as a lot of mutually dependent options. Or options that change meaning when together. We should improve the API.

See zeromq/libzmq#3551

Currently EpgmAddr is only a wrapper around String. Using the same interface (if possible), proper parsing (FromStr trait) and appropriate methods should be implemented.

See zmq_pgm for reference.

There are two non-mutually exclusive possibilities:

• Proxy the authentication at the zmq level by simply forwarding the requests to the remote server
• Proxy the authentication at the application level by creating a authentication protocol. This would allow implementation of authenticating services in userland.

Turns out that disconnect and unbind is the same exact function. I filled an issue in zeromq/libzmq#3529 to try to understand what the expected behaviour is.

Allow retrieval of the "Peer-Address" metadata, as defined in http://api.zeromq.org/master:zmq-msg-gets.

This AuthHandler would provide a convenient way to authenticate sockets via any mechanism.

• It should follow the ZAP specifications which describe a protocol that would achieve just that.
• It should support the any arbitrary mechanism such as plain or curve.

We could base our design on http://czmq.zeromq.org/czmq4-0:zauth.

Use the event monitoring API from #23 to create a socket event logger. This would fix #19 by emitting error messages when an authentication fails.

Things to consider:

• Use a global singleton logger vs. create a logger

See zeromq/libzmq#3552.

Since we enable ZAP by default, when no zap handler is running, send calls will hang forever.
There are 2 possible solutions I can think off:

• Create a spawn a ZAP handler for every context.
• Check for ZAP related events before sending to detect when a auth attempt failed. We could make bind and connect calls blocking a check whether the ZAP handshake was sucessfull.

It would be really helpful to be able to configure the AuthServer from a configuration file.

Filed this issue in libzmq.

Support the zmq_socket_monitored_versioned API to retrieve events for sockets.

My inital idea is to create a unique monitor_addr for each socket. Then we would call zmq_monitor_versioned with this addr to create a ZMQ_PUB monitor socket. The we could create a SocketMonitor which would leverage a ZMQ_SUB and subscribe to the appropriate events. It would then unpack the data into a SocketEvent enum and feed it to a user provided closure. If there is no significant overhead, we should enable that by default.

We could use the same API to create a event logger.

This is required to fix #19.

To allow polling via mio, the sockets must implement Evented. There a two ways to do so:

• Implement EventedFd using the zmq_poller file descriptor, which is currently blocked by zeromq/libzmq#2941
• Implement via the registration API, which seem to be destined for removal

The first one is clearly the better option.

ZMQ_LINGER is one of those unexpected features of ZMQ that is not all that useful in production. Real applications usually handshake and disconnect with ZMQ_LINGER=0.

We should consider setting ZMQ_LINGER=0 by default (or set the Ctx with no_linger=true by default). Maybe we should remove the set_linger option entirely.

Currently TcpAddr is only a wrapper around String. Using the same interface (if possible), proper parsing (FromStr trait) and appropriate methods should be implemented.

Note that TcpAddr is not exactly the same as SocketAddr since it supports the binding of interfaces etc.

See zmq_tcp for reference.

Currently InprocAddr is only a wrapper around String. Using the same interface (if possible), proper parsing (FromStr trait) and appropriate methods should be implemented.

See zmq_inproc for reference.

We should add a benchmark comparing with and without CURVE encryption.

See this issue for more info.

See zeromq/libzmq#3492.

Maybe a 3 level deep broker example to illustrate the routing_stack concept? We should use config files etc.

The general rational is that unlimited high water mark is basically useless.

First of all its a footgun that might encourage users to uncap their memory usage which will eventually lead to using all physical memory. Secondly, one could emulate this behavior by passing i32::max_value().

The zmq_poller is the new polling function that basically deprecates the old zmq_poll. We should implement it.

These are the thread safe equivalents of PUSH-PULL.

This are currently not documented in libzmq so we would have to reverse engineer how they work.

Instead of accepting a i32 and then later erroring out because the i32 was negative or zero, we should use stricter types. This would remove the type checking from the method.

For instance, we should mark the ErrorKind and Endpoint as non-exhaustive as well as add the #[non_exhaustive] attribute.

Blocked until stabilization.

This is a tracking issue around the proper implementation of Endpoint.

Currently Endpoint only parses the transport and stores the address into a string without parsing. This is meant to future-proof our socket methods until proper parsing is developed.

These are the sub-issues to must be closed:

• Implement TcpAddr #6
• Implement IpcAddr #7
• Implement InprocAddr #8
• Implement PgmAddr #9
• Implement EpgmAddr #10