Feature request: Transfer ownership of TcpClient to WebsocketClientLite library about websocketclientlite.pcl HOT 4 CLOSED

Thanks. Makes sense.

Implementing the transfer of ownership if the socket this way is fairly trivial, and it doesn't break anything as far as I can tell. I'll have look at it.

from websocketclientlite.pcl.

Interesting use case.

I'd be happy to take a look at this, but please allow me to ask a question:

You write that you don't know when to dispose of the connected instance socket connection that you're passing to the WebSocket Client. Why not closing/disposing it at the same time as you dispose the WebSocket Client, as that is effectively what would happen if the feature request is implemented? Or am I missing something here?

In any case, a way to implement this would be to introduce a boolean valueHasTransferTcpSocketOwnership in this constructor:

The HasTransferTcpSocketOwnership would by default be set to false but when set to true would always set the private property _keepTcpClientAlive to false :

from websocketclientlite.pcl.

I'd be happy to take a look at this, but please allow me to ask a question:

You write that you don't know when to dispose of the connected instance socket connection that you're passing to the WebSocket Client. Why not closing/disposing it at the same time as you dispose the WebSocket Client, as that is effectively what would happen if the feature request is implemented? Or am I missing something here?

Sure, I hope the following explanation will be clear enough, but if it isn't feel free to ask some follow-up questions.
Anyways, in order to start the connection, we simply need to subscribe to the MessageWebsocketRx instance (but we can only do so once as subscribing multiple times will try to start the connection process multiple times) and to disconnect again, we dispose our subscription, kicking in the that logic in the library and doing the further clean-up/disposal of other relevant resources.

However, in some of my usecases, I need to trigger a restart of the websocket connection. So I call the disconnect logic right before executing the connect logic again.

https://github.com/ErisApps/CatCore/blob/2790ad640602ef96ed0aa069f93ef44afa24dcce/CatCore/Services/KittenWebSocketProvider.cs#L45-L138

Given that the disposal of the subscriptions is fire-n-forget, it's very much possible that the closing/disposing of the TcpClient happens before the connection is gracefully shut down, resulting in exceptions being thrown from within the library. (which is the main reason why I created this issue in the first place 🙂 )

As for your proposed solution, that was very much the idea that I had in mind as well so that's completely fine for me.

from websocketclientlite.pcl.

Implemented in release 7.3.

from websocketclientlite.pcl.