Quitting TrackAudio won't close ws connection

[KingfuChan]

Finally I'm trying to implement the ws method into my RDF plugin. However I notice that when I quit TrackAudio directly (without disconnecting from AFV in prior), the ws is still connected in my RDF plugin. Starting a new instance of TrackAudio will not re-establish connection. Is it possible to make TrackAudio disconnects all ws connections whenever it is shutdown? This would save a lot of coding :)

[bostjanlaba]

That's odd. I have my own desktop software which acts as ws server, same as trackaudio in a way. If I close my app, the plugin I also developed for ES detects dropped connection (since ES plugin is the client in this case). So when I restart my desktop app, I need to issue some command in ES to reconnect. I do it thru ES cmd line like .genb connect and new connection is up.

In short, if TrackAudio is closed, all clients should notice the connection dropped....auto "reconnect" would probably work by constant retrying of opening new connection to trackaudio by the plugin (which could pose a problem to ES due single-threading) or rechecking at least for trackaudio ws server port being open.

So current RDF plugin is using hiddenwindow messaging still for communication with TrackAudio, not yet WS?

Edit: just noticed an info that your plugin is currently using rest api, so not hiddenwindow I guess :)

[neilenns]

That sounds like an error in coding the RDF plugin @KingfuChan. My StreamDeck plugin has no issue detecting when TrackAudio is no longer running and reconnects fine.

You can see the code I'm using here: https://github.com/neilenns/streamdeck-trackaudio/blob/c544eaa6bb1e56a61faacf19f8fb7d0a3286cdca/src/trackAudioManager.ts#L78, although I don't believe handing the close event directly is really necessary.

[neilenns]

Also Postman has no issue knowing TrackAudio isn't there anymore (I've been using Postman a lot to test websocket stuff during development)

[KingfuChan]

So current RDF plugin is using hiddenwindow messaging still for communication with TrackAudio, not yet WS?

For communication with standalone AFV client (only available in Windows), the hidden window messaging is used. But for VectorAudio/TrackAudio, the master branch is using HTTP SDK.

I'm using a light-weighted package ixwebsocket to realize WS SDK. Mostly referred to pierre's CoFrance plugin. However in my case I didn't even see the message of ws closing. Does it have anything to do with my environment, where TrackAudio and EuroScope runs on two machine (host and VM)?

[KingfuChan]

I've tried putting TrackAudio into VM where ES runs. It seems the WS close message is properly sent and received.

So I guess this becomes an issue when TrackAudio and ES are not in the same machine.

My TrackAudio was running on macOS Sonoma 14.5, M2 MacBook Air.

[bostjanlaba]

Generally it should not matter. When connection is closed, the client should know about it as this is how websockets work, it's still based on tcp/layer 4 of OSI, same as http in that matter. So I'd guess there's a problem in the ws sdk not properly capturing disconnection. But that is just a guess of course.

[neilenns]

So I guess this becomes an issue when TrackAudio and ES are not in the same machine.

I just tested by using Postman on my laptop with TrackAudio running on my desktop. As soon as TrackAudio closed Postman instantly realized the connection was gone.

Your issue doesn't appear to be related to TrackAudio at all. It's more likely that the VM isn't properly detecting the closed connection and passing it on to your app.

[KingfuChan]

I just tested by using Postman on my laptop with TrackAudio running on my desktop.

Have you tried platforms other than Windows? Perhaps this issue only happens in macOS?

[neilenns]

Unfortunately I only have windows available.

[neilenns]

I just tested by using Postman on my laptop with TrackAudio running on my desktop.

Have you tried platforms other than Windows? Perhaps this issue only happens in macOS?

You can try Postman on your end as well. Install it on your Mac with TrackAudio and create a web socket connection with it. Quit TrackAudio and see if Postman notices.

[KingfuChan]

Now I'm convinced something is broken under macOS build...

I used ChatGPT to write a simple py script to establish ws connection:

import asyncio
import websockets

async def receive_messages():
    uri = "ws://127.0.0.1:49080/ws"  # Replace with your WebSocket server URI
    try:
        async with websockets.connect(uri) as websocket:
            print("Connected to the WebSocket server.")
            try:
                while True:
                    message = await websocket.recv()
                    print(f"Received: {message}")
            except websockets.ConnectionClosed as e:
                print("WebSocket connection closed:", e)
    except Exception as e:
        print("Failed to connect to the WebSocket server:", e)

asyncio.run(receive_messages())

Step I did:

1. Start TrackAudio in macOS
2. Run the script in my macOS host
3. Close TrackAudio in macOS. The py script prints out:

Connected to the WebSocket server.
WebSocket connection closed: no close frame received or sent

4. Start TrackAudio in Windows 11 on ARM Parallels VM
5. Change the uri to VM's address and run the script again in macOS host
6. Close TrackAudio in Windows VM. It prints out:

Connected to the WebSocket server.
WebSocket connection closed: received 1000 (OK); then sent 1000 (OK)

[neilenns]

Interesting. While the e message is different, in both cases the Python library did detect the connection closed.

What happens if you run TrackAudio on the Mac but the Python script in the VM? That's the original scenario you were having issues with.

[KingfuChan]

What happens if you run TrackAudio on the Mac but the Python script in the VM?

It shows the same result no close frame received or sent, and the same result received 1000 (OK); then sent 1000 (OK) when script and TrackAudio is both running in VM.

[neilenns]

It shows the same result no close frame received or sent, and the same result received 1000 (OK); then sent 1000 (OK) when script and TrackAudio is both running in VM.

I sent you a private message on Discord, I've got a build of TrackAudio with a bunch of logging added for you to try if you can.

[pierr3]

Try the latest commit of TrackAudio, because I moved the close handler which may send out the appropriate close signal

[pierr3]

Closing as this should be fixed, reopen if needed.