Use cases for client application sending ABORT?

[ecorm]

My CppWAMP client library is currently taking care of automatically sending ABORT messages when it detects protocol errors in received messages. I'm considering allowing the users of my library to issue an ABORT via the library's API. However, I can't think of a use case where a client application would want to send an ABORT, instead of just cleanly leaving the session via GOODBYE, or abruptly disconnecting the transport.

Are there any use cases where a client application would want to send an ABORT for things that are not protocol errors or authentication failures?

[KSDaemon]

By the way, my library wampy.js also exposes abort() method.

The only case when it might be useful (and the only one I had in mind while making that api) is something like this:

The client starts connecting to the WAMP Router... But it takes some time (due to slow internet or some other reasons). If the client decides not to wait for session establishment — then it can call abort().

Yeah, I know not a very good example but as it is.

Calling abort during the session lifetime results in my case in simply closing the underlying websocket transport. It should not be used by clients to close sessions in normal ways.

[ecorm]

The client starts connecting to the WAMP Router... But it takes some time (due to slow internet or some other reasons). If the client decides not to wait for session establishment — then it can call abort().

This could be generalized to other operations where an acknowledgment (e.g. SUBSCRIBED) takes too long to arrive. Since CANCEL is limited to CALLs only, ABORT is the only available message left for the client to report a timeout for a non-call operation.

Calling abort during the session lifetime results in my case in simply closing the underlying websocket transport.

I would go further by sending an ABORT so that a reason URI can be logged by the router, followed by an immediate disconnection of the underlying transport.

[konsultaner]

@oberstet Why did you decide to have an ERROR and an ABORT and not just an ERROR in general?
And why does ERROR hava a payload and ABORT doesn't?

[konsultaner]

ok got it. Is there anything wrong with having ABORT being able to carry a payload just like ERROR. I would like to share some additional information with my users through the abort. I just think extending the message-dict part seems a bit dirty? also passing a JSON in the message would be a work around, but also seems a bit messy?

[ecorm]

Is there any reason why other members (other than message) cannot be added to the ABORT.Details dictionary to convey additional information?

[KSDaemon]

@konsultaner Yeah I agree with @ecorm  - we have a Details|dict in almost all types of messages. And besides spec-defined attributes, you can provide some of your own too. The spec doesn't state that these Details should not hold only spec-defined attributes. Moreover, we're discussing the custom attributes (#345). So if you'll go that way — consider making it more close to our proposals/discussions, 'cause I hope we'll finally describe that in the spec someday :)

[oberstet]

yeah, custom attributes (#345) are effectively required to make our approach of adding Details|dict to all (almost?) WAMP messages - the protocol should be extensible by a user (implementer) in an easy way.

so yes, definitely, ABORT.Details could be used by implementations to carry additional information for the situation when ABORT is sent

https://wamp-proto.org/wamp_latest_ietf.html#section-3.4.1.3

[konsultaner]

@ecorm No, it could be done, sure! The Details|dict is just a part of the message head and therefor a definite part of the deserialization inside the router. kwargs and args may be passed as opaque payload even e2e encrypted. Depending on how sensitve your information is, you may not or cannot send them in the Details|dict. It's also a matter of performance. If the Details|dict holds a lot of data, sending with zero copy has quite an impact.