Skip to content
This repository has been archived by the owner on Nov 28, 2020. It is now read-only.

Socket notifications #123

Open
jean-airoldie opened this issue Sep 2, 2019 · 1 comment
Open

Socket notifications #123

jean-airoldie opened this issue Sep 2, 2019 · 1 comment
Labels
feature request A request for a new feature
Milestone

Comments

@jean-airoldie
Copy link
Owner

By leveraging the zmq_socket_monitor API, allow sockets to receive events that are normally discarted by libzmq. Allow the user to configure what events should be received or discarded.

See #122 for more information.

@jean-airoldie jean-airoldie added the feature request A request for a new feature label Sep 2, 2019
@jean-airoldie jean-airoldie added this to the 0.3 milestone Sep 2, 2019
@jean-airoldie jean-airoldie changed the title Socket event filtering Socket notifications Sep 3, 2019
@jean-airoldie
Copy link
Owner Author

This would be a way better approach zeromq/libzmq#3658.

This would essentially allow us to configure a socket to receive notifications in Msg based on a set of interests. The interests would be something like a bitflag that would tell zmq what events we are interested it. By default, sockets would have no interests, aka. stateless.

Here are the possible approaches for passing events to the user:

As a Msg

let msg = client.recv_msg()?;
if msg.is_notif() {
  match msg.notif() {
    Notif::Disconnected => ...,
    _ => ...,
  }
} else {
  // proceed like normal.
}

Pros

  • No additionnal complexity for stateless sockets

Cons

  • Not ergonomic

As the content of a Msg

  let msg = client.recv_msg()?;
  match msg.content() {
    Content::Bytes(bytes) => ...,
    Content::Notif(notif) => ...,
  }

Pros

  • Ergonomic

Cons

  • Additionnal complexity for stateless sockets

As an error

  match client.recv_msg() {
    Ok(msg) => ...,
    Err(err) => match err.kind() {
      ErrorKind::Notif(notif) => ...,
      _ => ...,
    }
  }

Pros

  • Ergonomic
  • Not additionnal complexity for stateless sockets

So I think that the notification as an error approach is the best one. Even if there is some metadata contained within the message, we can retrieve it and give it back to the client.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature request A request for a new feature
Projects
None yet
Development

No branches or pull requests

1 participant