Erik, I can't explain why this condition is holding (when a read is pending, closing the socket stream has no effect until the timeout expires, all client side). I would stick with your solution: | server client | server := ZnWebSocket startServerOn: 1701 do: [ :webSocket | [ webSocket runWith: [ :message | Transcript show: 'Received message: ', message printString; cr ] ] on: ConnectionClosed, PrimitiveFailed do: [ "ignore close" ]. Transcript show: 'The server websocket is closed @ ' , DateAndTime now asString; cr ]. client := ZnWebSocket to: 'ws://localhost:1701'. [ [ client runWith: [ :message | "ignore received messages" ] ] on: ConnectionClosed, PrimitiveFailed do: [ "ignore close" ]. Transcript show: 'The client websocket is closed @ ' , DateAndTime now asString; cr. server stop ] fork. 10 milliSeconds wait. client sendMessage: 'Hello world! #' , 999 atRandom asString. "client close." "Workaround: use the following instead of 'client close'." client sendFrame: ZnWebSocketFrame close. { server. client }. I checked and no resources are lost at the end (the socket/stream gets cleaned up). I would lower the timeout in any case, 30s is way too long, I would go for 5s or 10s. Sven

On 5 Jun 2020, at 09:55, Erik Stel <erik.stel@gmail.com> wrote:

Hi Sven,

(I hope this message does arrive. Sorry for the late reply. I have not been able to use the browser-interface for the ML for a number of days now. An admin could not figure this out either. So resorting to actually using a mail ;-)

My architecture is one in which client and server are working fairly independent. A client or server can send the other a message whenever it wants (and there is no response expected). The client is responsible for setting up the connection and keeping it ‘open’ (for the server to reach the client). When the client wants it can however disconnect and reconnect at a later time. The server will still be there (this is not visible in the example of course). Both client and server keep track of messages which can’t be sent when the connection is (temporarily) down.

So I have to have a separate process to read messages from the process that writes messages to the WebSocket. In a test I discovered that closing the connection from the client did not get noticed in the process doing the reading. I’d like that process to stop running fairly directly since it is performing some additional logic. Now it takes a timeout. Closing the connection using the specified workaround does get noticed and works for me. But I’m unsure if this is a good approach and there’s the risk it will not work on a next update. A shorter timeout could be a solution but does mean I’m going into a ‘polling’ mode. So I think I prefer my workaround over setting a very short timeout.

If you have a better solution though, please let me know.

Kind regards, Erik