Correlate WAMP messages

[darkl]

Phase II: now we have decoded WAMP messages, we would like to see correlated messages together. We have some messages that are actually "request-response", some of those include

• SUBSCRIBE => SUBSCRIBED (by request parameter), ERROR (by type = SUBSCRIBE and request parameter)
• REGISTER => REGISTERED (by request parameter), ERROR (by type = REGISTER and request parameter)
• CALL => RESULT (by request parameter), ERROR (by type = CALL and request parameter)
• PUBLISH => PUBLISHED (by request parameter), ERROR (by type = PUBLISH and request parameter)
• UNSUBSCRIBE => UNSUBSCRIBED (by request parameter), ERROR (by type = UNSUBSCRIBE and subscription request)
• UNREGISTER => UNREGISTERED (by request parameter), ERROR (by type = UNREGISTER and request parameter)

I think it can be cool to display this somehow similarly to browser HTTP request/response.

Elad

[darkl]

@oberstet

[janodvarko]

Great!

How would you expect the UI/UX to look like?

Honza

[darkl]

I guess for request messages I'd like to have an additional response tab that displays the response. For response messages I'd like to have similarly an additional request tab that displays the request. A timing tab like the one we have for HTTP messages will be also awesome.

[oberstet]

Yeah, that kind of correlating request/response exchanges would be highly useful!

Btw: one interaction is missing: INVOKE => YIELD (by request parameter), ERROR (by type = INVOKE and request parameter) .. essentially the callee role. As AutobahnJS supports running callees even in browser tabs, messages of type INVOKE and YIELD will be encountered.

[darkl]

Yeah @oberstet is right, but note that INVOKE is a bit special since it is a router to client frame and in this case YIELD/ERROR are client to router frames.

Elad

[darkl]

@oberstet, Also note that YIELD is more complicated since we have progressive calls so we might have more than one response to a request... I think work on INVOKE should be postponed to a later phase. (When we would also like to correlate EVENT messages to SUBSCRIBE/SUBSCRIBED messages)

[darkl]

@oberstet Actually I regret my last message, since we have the same problem with CALL/RESULT. I guess in this phase we'll consider only single request/response message, we will assume no progressive calls.

Elad

[oberstet]

Yeah, I think INVOKE/YIELD without progressive results (or progressive arguments) are no more complex than the other strict request-reply exchanges. Progressive results (or arguments) are one dimension of complexity. Correlating events with subscribes (and publishes), or calls with registers (and invocations) is another dimension of complexity - and it doesn't appear to work on a strict browser side anyway, since only the router has insight at that level. So I think it could make sense to limit decoding support to strict request-reply message exchanges for now - maybe adding progressive request-reply exchanges later.

[oberstet]

But I agree, there is a difference nevertheless: INVOKE comes in actively over the wire from a browser point of view. With CALL, REGISTER and SUBSCRIBE, the browser is the initiator of the request-reply exchange.

So the minimum scope could be: all strict request-response exchanges without progressive option, and with the browser being the request initiator.