I CC the Autobahn list for this WAMPv2 discussion
I'd support a 2 stage approach. Pls see below. Rgd your specific
points I comment inline. Sorry, this has gotten long, but pls
provide feedback/comments - I'd like to nail it down.
Stage 1: Attack the minimial-viable solution
That would be an optional 4th argument in EVENTs:
[ TYPE_ID_EVENT , topicURI , event ]
[ TYPE_ID_EVENT , topicURI , event , publisherSessionID ]
- required in any case (whether publisher, consumer or server decides about including the publisher session ID)
- If clients dont want/understand, they can just ignore beyond 3rd arg.
- Minimal change to client APIs.
- Very secure: server/admin can decide whether publisherSessionID is disclosed on a topic.
- Minimal change to server APIs: dispatch(.. disclosePublisherSessionID = True | False) and registerForPubSub(.. disclosePublisherSessionID = True | False)
- No impact on optimized dispatching (serialize once, transmit many)
So I'd like to poll opinions on having above included in WAMPv2
There is still an open issue even with this "simple" extension:
what exactly is the content of publisherSessionID?
a) In case the EVENT was actually published by some client, thats
easy: publisherSessionID = WAMP session ID of the client publishing.
b) In case the EVENT was dispatched by the server in the course of
a RPC done by some client, is the publisherSessionID then the
WAMP session ID of the client doing the RPC or some special "SERVER"?
c) In case the EVENT was dispatched by the server on it's own,
is there any publisherSessionID at all, and if so some special value
d) In case the EVENT was submitted to the broker by some external
system, then dispatched by the broker. What is publisherSessionID?
The use of magic strings like "SERVER" makes me uncomfortable: it
imposes additional rules upon how to generate session IDs, and what
values are not to be used.
We might as well just use the empty string "" as special value.
We might also use the value NULL (which can still be distinguished from publisherSessionID being absent) .. but we want to get rid of the
types BOOLEAN and NULL in WAMPv2:
And lastly, there is
Making WAMPv2 fully symmatric might involve having both peers in
a WAMP session assigned an ID. If so, that might ease b+c.
There are 2 conceivable uses for publisherSessionID in EVENT by client:
1. later use the ID for exclude/eligible during publish
2. correlate events: 2 events having same publisherSessionID
come from the same source session
1. is the main case. 2 is questionable IMHO, since session IDs
We need to also agree whether the following holds:
_If_ there is a publisherSessionID present in some event, that
implies that the value can be used in PUBLISH within exclude/eligible.
If so, then "special values" for publisherSessionId are problematic.
I can't publish to some topic with eligible = ["SERVER"]
I think, at this point, it might be most valuable to further discuss
above open issues and reach agreement on that.
Stage 2: Given above would be in WAMPv2, discuss where above might still be lacking, what could be done
I am open for that also (just wanted to split out the minimal viable,
I can see Stage 1 lacking in these respects:
1) A client may receive the publisher's session ID when it's not interested. It can just ignore the data, but there is (small) needless traffic on the wire here.
- (small) reduction in traffic
- easy extension to SUBSCRIBE message (optional 3rd parameter)
- requires extension of SUBSCRIBE message
- extension of client APIs
- change server dispatching code (under serialize-once/transmit-many)
2) A publisher might not want to disclose it's session ID at all on a topic (or for a given publish).
Are there viable cases for this?
Obviously, an extension to PUBLISH message is needed. My main concern here is: https://github.com/tavendo/wamp/issues/5
The PUBLISH message variants ... proliferation.
Am 27.07.2012 20:45, schrieb Jordi Marinï¿½ Fort:
Overall I tend to agree it can be useful in situation ..
However, let me note this: in principle PubSub is exactly about consumer
and producers _not_ knowing each other - decoupling.
So we need to be careful ..
What are you planning to do with a subscriber knowing the session ID
of the producer of a specific event?
Multi-player game communications.
I see. This use case should definitely have good support in WAMP.
Right, WAMP already allows to use the session ID again in publish
exclude/eligible lists, so technically, it would probably be consequent
and have events (optionally) carry a session ID.
Good point. This feature would also be useful to "discover" the
sessionId for sending replies to the publisher.
One thing to be aware of: the session ID is totally transient and only
exists for the lifetime of a WAMP session. It's gone thereafter.
The session ID is not some kind of permanent "client ID" ..
Would be interesting to know more about your use case ..
On starting a game match, a new topic will be created, and the
interested players/observers will SUBSCRIBE to it, so they can receive
action events from the other players.
The players may send the action events directly (PUBLISH messages), or
through RPCs (with server validation and broadcasting of EVENT messages).
But in this situation, "fake" clients could PUBLISH "event objects" like
those generated by server/other players, and they will be broadcasted in
the same manner.
Imagine a chess game player, waiting for a "move" EVENT from the
opponent, but it receives a valid "move" event that has been directly
published by a "cheating" observer...
With the publisher's "sessionId" in the EVENT, the clients could check
the message comes from a valid source (the "server" or the expected
players), before trusting the event object content.
If we add (optional) session ID to events, that should definitely done
by the server. Doing so is trivial. It's a question whether we want it
There are 3 parties which could decide whether to augment an event
with producer session ID:
With 1.: The producer would not include it's session ID literally,
but only signal the server to do so.
I don't need this case. Maybe you have found a use case?
I don't have. The idea was to allow the client to "opt-in" and "opt-out"
of having it's session ID disclosed, without the client being able to
fake the publisherSessionId.
With 2: This has a undeseriable consequence: for 1 event there may
be subscribers that do want the session ID, and others that do not want.
This means that a message cannot be serialized once, and then blindly
sent to all subscribers (which is a performance optimization done by
I will try to change your mind about this case:
- If the consumer decides, it will not always force undesired traffic.
- At worst, it will only require 2 EVENT serializations (with or without
- I think there code required to add this feature will not be overkill
(add subscription property, and send the correct EVENT message to each
- But if you want to blindly send the same EVENT message to all
subscribers, maybe you can check if any subscription has required this
feature (topic property), and generate/send the same EVENT with/without
the publisher sessionId to all clients (and consumers that doesn't need
this information, can easily ignore the 4th argument).
Can be done, sure. It complicates code though (need to maintain 2 lists
of subscribers per topic). The latter is not a very strong argument I agree. On the other hand the advantage of saving a couple of bytes traffic per EVENT is also of limited attraction. Lets get "Stage 1"
agreed and the return to this ..
With 3: Most "secure". The server developer/admin decides whether events
disclose their producer.
It will force undesired traffic, but it could be useful that
"admin"/"developer" can deny/allow this feature
(only disclose the publisher sessionId when allowed and also requested
by consumer in the SUBSCRIBE request ).
Another feature I'm interested, is that the developer of server RPCs
would be able to decide between:
- sending EVENT messages with the "sessionId" of the client that made
- sending EVENT messages with the "server" identification (that clients
can check that it is a trusted publisher).
But I think these features are out of scope of the specification,
because they will depend of the APIs/configuration files provided by the
Yep. When stuff like this gets into WAMPv2, AutobahnXX will of course
make machinery/APIs available to also use it.
I agree it should be optional. I am not sure about which of 1.-3. of
above should decide ..
I vote for case 2.
Maybe should I open an github's issue at "WAMP" specification
Yes, please! Submit an issue on
and tag it with the existing Label "WAMPv2" ..
I've just submitted the issue:
But I don't know how to tag it with the "WAMPv2" label.
Done. (On the right side on the GitHub issue, you have a label drop-down ..)
Thank you for the reply.