Consumer cleanup behavior

[danielpeintner]

@relu91 raised concerns int a call w.r.t. cleaning up client connections

We have a problem in node-wot that CoAP clients are not being closed which causes hanging … should we add something like a destroy method to the ConsumedThing? … socket is currently not being closed. Problem is not limited to CoAP, however, also relevant for WebSockets, for example

see https://www.w3.org/2022/03/28-wot-script-minutes.html#t05

[danielpeintner]

@JKRhb

• cancellation of subscriptions might be a use-case. not a read operation.
• CoAPs scenario... opening connection might be useful for constrained devices @relu91
  • shortcut for looping for unsubscribe ...
  • timeouts are work-arounds.. not a recommendation
  • close after each operation might be possible ...even for WS .. performance penalty @zolkis
• look at number of possible connections

NAMING: stop() / free() / ? destroy() / shutdown() .. semantic issue Re-using connection?

[danielpeintner]

@JKRhb

• bug in node-coap caused the hanging problem.
• session open for long time. Opening new session is expensive. Re-using makes sense.
• having stop() / free() / ? destroy() / shutdown() still makes sense

@danielpeintner

• stop() is just a hint ... call will precede timeout

[relu91]

call 16/05

• should we recommend using the stop method always? we can clarify this with the algorithm and specific teardown steps.
• @zolkis previously stop was meant to close all ongoing communication and free the resources
• probably we should also add a start method: (open connections? creates system resources? )
• Currently, we have a factory, therefore start might not be strictly needed.
• See Generic Sensor API
• In general, this is related to session management

We can start discussing this in a PR

[danielpeintner]

Sorry for missing the call

• See Generic Sensor API

Do you mean the Generic Sensor API is an argument of having start() and stop(), right?

Most of the protocols are RESTful meaning no need to setup or do some pre-processing. WebSocket for example is an exception where setting up the connection might be useful. For other protocols it might be a void operation.

Question1: Does the TD provide the necessary information. I recall discussions that we were looking for a way to initialize the connection.

Question 2: having a stop() method might also mean we require a re-start() method.. maybe.. or starting over again.

[zolkis]

The behavior of start() and stop() might differ based on underlying protocols. If those don't require any setup, the only thing is enabling or disabling notifications and serving Things. I think it's pretty okay design to have start() and stop(), because of

• separating object constructors from network operations (setup, teardown, mapping to connection management)
• already a pattern used in similar APIs
• allows a mapping to connection management (if needed) inside implementations/protocol adapters, while allowing scripts to control it, or at least express their hint from UX perspective. We can specialize these behaviors in the algorithm definitions in the spec.

[JKRhb]

If I see it correctly, the result of our discussion here was to add both a start and a stop method to the ConsumedThing class, right?

[danielpeintner]

If I see it correctly, the result of our discussion here was to add both a start and a stop method to the ConsumedThing class, right?

I am not sure if we really should do that.

• startis similar to what we do now with the factory method WoT.consume(). Otherwise it gets clumsy and people most likely do forget to call start() first etc...
• having stop somehow makes sense to me to force cleaning-up resources but I am not really sure either ...

Personally, I think it is good enough what we have now

[zolkis]

I agree that stop() would be enough. We can add it later, when the use case becomes clear (and requested).