You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Nov 28, 2020. It is now read-only.
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.
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.
By leveraging the
zmq_socket_monitor
API, allow sockets to receive events that are normally discarted bylibzmq
. Allow the user to configure what events should be received or discarded.See #122 for more information.
The text was updated successfully, but these errors were encountered: