Hi Erik, I am afraid I do not fully understand what your problem is.
Also, I see no code. Server side, a web socket connection is automatically kept open (it has to be). Client side, you should study #runWith: and how it is used. Recently I added sending #ping keep alive message to the runWith: loop (as browsers do the same). HTH, Sven > On 29 May 2020, at 12:39, Erik Stel <erik.s...@gmail.com> wrote: > > Sven or anyone else with experience with ZnWebSockets, a question regarding > ZnWebSocket usage. > > I have the following code which sort of resembles my current usage of > ZnWebSockets. ZnWebSockets are used for both sending and receiving messages > in a random fashion (ie, no request-response like pattern). Because the > ZnWebSocket operates synchronous I fork 'handlers' which process the > incoming messages. When executing the code below, the client closes the > connection but will 'recognise' this itself only after a timeout (around 30 > seconds by default). Is there a better way to use ZnWebSockets which does > not incur this delay? > > My current workaround (see comment at the bottom in code below) is to send > an explicit "close" ZnWebSocketFrame instead of sending #close to the > ZnWebSocket. This will have the client close 'directly', after which I can > close the ZnWebSocket stream explicitly. The implementation of #close for > ZnWebSocket is to perform both: send close frame and close stream. The later > seems to 'stall' the receive message until timing out. The synchronous > handling of incoming messages might be causing this. But could not directly > find why closing the stream resulted in different behaviour than when only > sending the close frame. (Hope this explanation is helpful ;-). > > > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >
