Fire-and-forget messages?

[Emile Cormier]

Has there ever been any discussion about the need for fire-and-forget messages between peers? This would be like an RPC, except that the caller doesn't wait for a response, and the callee doesn't return a result.

I'm not sure that the existing pub-sub would work for this purpose, because any peer could listen to sender.

We currently have no such need in our application, but I was wondering if there are use cases where this feature would be useful.

[Konstantin Burkalev]

Hi, Emile! 

Well, i think there is no need for creating special thing for a such case. 

You can achieve this with current pub/sub. You can set AP option: 

 eligible: integer|array WAMP session id(s) that are allowed to receive a published event

With this you can subscribe all clients to one topic, and control the receivers with just eligible option when publishing.

Also note, there is exclude option, which is reverse for eligible.

 exclude: integer|array WAMP session id(s) that won't receive a published event, even though they may be subscribed

среда, 7 февраля 2018 г., 9:53:32 UTC+3 пользователь Emile Cormier написал:

[Emile Cormier]

Thanks Konstantin. I somehow knew there would be an AP that allows this. It's been a while since examined all the AP features.

--
You received this message because you are subscribed to a topic in the Google Groups "WAMP" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wampws/qyXYnrSThpg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wampws+unsubscribe@googlegroups.com.
To post to this group, send email to wam...@googlegroups.com.
Visit this group at https://groups.google.com/group/wampws.
To view this discussion on the web visit https://groups.google.com/d/msgid/wampws/c807c528-a33f-4a51-b4cd-c5d3b76e8add%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Konstantin Burkalev]

NP! You're welcome! :)

[Emile Cormier]

Upon further thought, the eligible option would require that the peer knows the session ID of the other peer.

What I'm proposing would be sending a fire-and-forget message to a "mailbox" with a known URI.

What we call "RPC" in WAMP might have been better named "mailbox". There could have been two modes for sending to a mailbox:

• Request-Response (aka RPC)
• Fire-and-forget

A "send to mailbox" feature could be added by defining a "no_response" option for the CALL and INVOKE messages.

BTW, the motivation for my question came when I stumbled upon this: https://github.com/Tixit/RPEP

[Alexander Gödde]

You could have a URL for these messages for which you configure event history -  https://crossbar.io/docs/Event-History/ so that clients offline at the time of the sending can retrieve the event at a later time. 

--
You received this message because you are subscribed to the Google Groups "WAMP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wampws+unsubscribe@googlegroups.com.

To post to this group, send email to wam...@googlegroups.com.
Visit this group at https://groups.google.com/group/wampws.

To view this discussion on the web visit https://groups.google.com/d/msgid/wampws/3bcfaffe-62ed-4f3f-838d-d7e46009e012%40googlegroups.com.

[Tobias Oberstein]

Hi,

just quickly ..

Am 07.02.2018 um 20:55 schrieb Emile Cormier:
> Upon further thought, the *eligible* option would require that the peer

> knows the session ID of the other peer.
>
> What I'm proposing would be sending a fire-and-forget message to a
> "mailbox" with a known URI.
>
> What we call "RPC" in WAMP might have been better named "mailbox". There
> could have been two modes for sending to a mailbox:
>

> - Request-Response (aka RPC)
> - Fire-and-forget
>
> A "send to mailbox" feature could be added by defining a *"no_response"*

> option for the CALL and INVOKE messages.

we could do that easily, but this is merely an optimization detail:

you can just return "void", and throw away / don't wait for a call
result in the callee

so all that does is save some bytes on the wire

>
> BTW, the motivation for my question came when I stumbled upon
> this: https://github.com/Tixit/RPEP

this isn't routed, so it doesn't provide decoupling, and all the nice
things that come with it. big step backward. not interested in that ..

cheers,
/tobias