EVENT message with an identifier of the publishe about wamp-proto HOT 7 CLOSED

WAMPv2 will allow a publisher to request the broker to identify itself (the publisher):

 [PUBLISH,      Topic|uri, Event|any, PublishOptions|dict]

 PublishOptions = {IDENTIFY_ME: IdentifyMe|boolean}

The publisher's request to identify himself might or might not be honored by the broker. Hence the request is a hint.

Should the broker decide that for a particular publish the publisher should be identified (either because of a publisher's request that got honored, or by the broker deciding itself), the event will look like

 [EVENT,        Topic|uri, Event|any, EventDetails|dict]

 EventDetails = {PUBLISHER: SessionID|string}

from wamp-proto.

Mmm... I'm reconsidering my proposal (feature requested at subscription time), and I'm realizing that your proposal is a better choice (it only increase the traffic payload when needed and it seems easiest to implement).
It could also serve for my purpose (check/trust the messages published from clients), but how could the client check/trust if the message comes from the server?
(maybe using a special "SERVER" string as the "PUBLISHER", instead of the "SessionID")

By other side, I've been also reading the work on WAMPv2 spec at:
https://github.com/tavendo/wamp/blob/master/WAMPv2.md

Could you explain the "PUBLISH_ACK" message ?
(with a little example of HEARTBEAT/PUBLISH/PUBLISH_ACK messages between the client<-->server)

Thank you for considering this feature for WAMP v2.

from wamp-proto.

I'll address all your points/questions .. will reply in multiple parts though (gets too long otherwise);

Regarding Subscriber opt-in/opt-out.

Using the new

[SUBSCRIBE,    Topic|uri, SubscribeOptions|dict]

message type, which provides extensiblity, it would - in principle - be possible to add

SubscribeOptions = {IDENTIFY_PUBLISHER: IdentifyPublisher|booelan}

so that a subscriber can opt-in/out of receiving publisher session IDs in cases where the broker is willing to send it.

However, the only advantage I see is a small saving on wire-level traffic.

On the other hands it makes broker implementations more complex, since the broker now might need to maintain 2 message serialization for events: 1 for subscribers that opted-out, and 1 for subscribers that should receive publisher session IDs.

Currently, I am leaning towards NOT having above opt-out for subscribers.

from wamp-proto.

I'm agree, so I'm changing my former vote for:
+1 to ONLY have the option in the PUBLISH message to enable this feature (instead of requesting it with an option of the SUBCRIBE message)

from wamp-proto.

Being able to determine the "trust level" that one should put into events received is definitely a valid use case, and we need to address it.

I now think "trust level" is orthogonal to "publisher ID". The presence of a publisher ID (= client WAMP session ID) might be indicative of the trust one is putting into the event, but its primary use is with eligible and exclude.

We need to address the "trust level" issue in various situations:

• events dispatched by code embedded inside the broker (for example when using AutobahnPython as the basis for an application specific broker).
• events dispatched by a broker coming in via a gateway API the broker provides. E.g. the broker might expose a REST API for receiving events to be dispatched into the WAMP world.
• events dispatched from inside a database stored procedure, the broker again implementing a gateway to the database
• probably even: have WAMP clients connecting from inside a network and hence having certain IPs assigned a higher trust level than clients coming from outside

That last example really is a use case where the presence of a publisher session ID alone would be insufficient to determine the trust level.

Hence I'd propose to have

 [EVENT,        Topic|uri, Event|any, EventDetails|dict]

where

 EventDetails = {TRUSTLEVEL = TrustLevel|integer}

and TrustLevel being an non-negative integer where 0 indicates lowest level of trust, and higher numbers indicate increasing trust levels.

Whether a trust level is indicated in the event, and if so, which level, has to be completely under control of the broker. Which is the whole point of having a trust level: it needs to be reliable.

from wamp-proto.

Regarding PUBLISH_ACK, I'll try to write more inside the spec document over the weekend ..

from wamp-proto.

Both disclosing publishers and trust levels is now in WAMPv2 and can be provided in EVENT messages:

 [40, 5512315355, 4429313566, {"publisher": 3335656}, "com.myapp.mytopic1", "Hello, world!"]
 [40, 5512315355, 4429313566, {"trustlevel": 2}, "com.myapp.mytopic1", "Hello, world!"]

from wamp-proto.