No solution for client websocket desktop air app, please help!

[JoseEstevesPt]

I'm using Adobe Animate 24.0.3 and Air SDK 50.2.4.4, creating a desktop app that connects do websockets (websockt or websocket IO) server, I've tried all the old libraries, help of chat GPT, help of Copilot, nothing works. Then I saw this post...How can I get AIR SDK 51? will I be able to solve my problem. Please help!

Discussed in https://github.com/airsdk/Adobe-Runtime-Support/discussions/3081

^{Originally posted by ajwfrost February 23, 2024} Hi all. Finally, we are releasing a new major version of the AIR SDK - the major version update is because of a number of new ActionScript APIs and features that are being added, which means the SWF version code will also be going up to 51 (fourth byte of the SWF = 0x33).

This discussion thread is to provide information about the new features/APIs. Our intention is to create a new main comment for each of the features, and then we (or anyone) can reply on those comment threads, so that we keep each thread specifically about a particular feature. We can then use it to give examples, provide updates on the status (51.0 is released initially as a beta/pre-release, some features are not actually completed), and hopefully it still stay roughly organised.

For full ActionScript API details, check out the "What's New" page of https://airsdk.dev/reference/actionscript/3.0/

[ajwfrost]

You can download AIR SDK 51 by selecting the version from https://airsdk.harman.com/release_notes (I just noticed we hadn't updated the 'default' SDK version from the downloads page..)

But if you wait 12 hours, we should have 51.0.1.2 available which fixes a number of issues and would be better to use..

thanks

[JoseEstevesPt]

thanks Andrew, meanwhile I discovered the air sdk manager and downloaded air sdk 51.0.1.1 but I'me still struggling and can't make the connection work. Where can I find a simple code example?

[ajwfrost]

Well it should be a fairly straightforward thing, but having just tried it here, we seem to have some issues with the client-side connection. It's one of those that worked when we tried it locally, but trying it again now and I've just noticed a couple of problems.

Sample code, if you're connecting from AIR to a websocket server elsewhere:

		private function testWebSocket() : void
		{
			// create a connection to the websocket echo server
			_ws = new WebSocket();
			_ws.addEventListener(Event.CONNECT, onConnected);
			_ws.addEventListener(WebSocketEvent.DATA, onData);
			_ws.addEventListener(IOErrorEvent.IO_ERROR, onError);
			trace("Connecting to web socket test echo server");
			_ws.connect("wss://echo.websocket.org/echo");
		}
	
		private function onConnected(e : Event) : void
		{
			// send a test message
			trace("Connected: sending a message");
			if (_ws) _ws.sendMessage(WebSocket.fmtTEXT, "This is a test message");
		}
		
		private function onData(e : WebSocketEvent) : void
		{
			trace("Received data from the message");
			var msg : String = e.stringData;
			trace(msg);
		}
		
		private function onError(e :IOErrorEvent) : void
		{
			trace("Error connecting to server: " + e.text);
		}

We've just been finding that sometimes, the secure socket connection doesn't work - which appears to be a garbage collection issue (we use an internal instance of a socket within the websocket implementation and the mechanism used to prevent this from being GCed seems to not be working?).

And also we've just noticed that the test server used above is sending responses with different capitalisations to the requests, which our earlier test server didn't do, and this has then exposed an issue in the code.

So .. it may well not connect properly... are you trying to connect to anything public that we can check against? or if you are able to find out what network packages (at least the http messages) are being sent/received, we can take a look at those to see where it's going wrong.

We'll get fixes out in the next release (well, 51.0.1.3, a few weeks away I'm afraid) to try to resolve these..

thanks

[ajwfrost]

Hi @JoseEstevesPt - can I check what operating system you're using to build/test this? We could share an update to try out perhaps?

[JoseEstevesPt]

Thanks once more, here is the code I’m using (yours of course), I’m using as a test server "wss://gr8events.tech/teste”, can’t connect getting one warning and one error.

Warning: Scene 1, Layer 'Layer_1', Frame 1, Line 28, Column 10 Warning: 1090: Migration issue: The onData event handler is not triggered automatically by Flash Player at run time in ActionScript 3.0. You must first register this handler for the event using addEventListener ( 'data', callback_handler).

Error: Connecting to web socket test echo server Error connecting to server: Error #2031: Socket Error. URL: gr8events.tech http://gr8events.tech/

I’m running Animate on macOS Sonoma version 14.5

import flash.events.Event; import flash.events.IOErrorEvent; import flash.events.SecurityErrorEvent; import flash.events.WebSocketEvent; import air.net.WebSocket;

var _ws:WebSocket _ws = new WebSocket(); _ws.addEventListener(Event.CONNECT, onConnected); _ws.addEventListener(WebSocketEvent.DATA, onData); _ws.addEventListener(IOErrorEvent.IO_ERROR, onError); trace("Connecting to web socket test echo server");

//_ws.connect("wss://echo.websocket.org/echo");

ws.connect("wss://gr8events.tech/teste");

function onConnected(e : Event) : void { // send a test message trace("Connected: sending a message"); if (_ws) _ws.sendMessage(WebSocket.fmtTEXT, "This is a test message"); }

function onData(e : WebSocketEvent) : void { trace("Received data from the message"); var msg : String = e.stringData; trace(msg); }

function onError(e :IOErrorEvent) : void { trace("Error connecting to server: " + e.text); }

On 31 May 2024, at 00:23, Andrew Frost @.***> wrote:

Well it should be a fairly straightforward thing, but having just tried it here, we seem to have some issues with the client-side connection. It's one of those that worked when we tried it locally, but trying it again now and I've just noticed a couple of problems.

Sample code, if you're connecting from AIR to a websocket server elsewhere:

  private function testWebSocket() : void
  {
  	// create a connection to the websocket echo server
  	_ws = new WebSocket();
  	_ws.addEventListener(Event.CONNECT, onConnected);
  	_ws.addEventListener(WebSocketEvent.DATA, onData);
  	_ws.addEventListener(IOErrorEvent.IO_ERROR, onError);
  	trace("Connecting to web socket test echo server");
  	_ws.connect("wss://echo.websocket.org/echo");
  }

  private function onConnected(e : Event) : void
  {
  	// send a test message
  	trace("Connected: sending a message");
  	if (_ws) _ws.sendMessage(WebSocket.fmtTEXT, "This is a test message");
  }
  
  private function onData(e : WebSocketEvent) : void
  {
  	trace("Received data from the message");
  	var msg : String = e.stringData;
  	trace(msg);
  }
  
  private function onError(e :IOErrorEvent) : void
  {
  	trace("Error connecting to server: " + e.text);
  }

We've just been finding that sometimes, the secure socket connection doesn't work - which appears to be a garbage collection issue (we use an internal instance of a socket within the websocket implementation and the mechanism used to prevent this from being GCed seems to not be working?).

And also we've just noticed that the test server used above is sending responses with different capitalisations to the requests, which our earlier test server didn't do, and this has then exposed an issue in the code.

So .. it may well not connect properly... are you trying to connect to anything public that we can check against? or if you are able to find out what network packages (at least the http messages) are being sent/received, we can take a look at those to see where it's going wrong.

We'll get fixes out in the next release (well, 51.0.1.3, a few weeks away I'm afraid) to try to resolve these..

thanks

— Reply to this email directly, view it on GitHub https://github.com/airsdk/Adobe-Runtime-Support/issues/3274#issuecomment-2140995050, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE52QAECS5VQ6CJJYCUJO73ZE6YFVAVCNFSM6AAAAABIRTABJWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBQHE4TKMBVGA. You are receiving this because you authored the thread.

[ajwfrost]

Thanks

So .. with the changes we've just made here, we can connect to the echo service and send/receive messages now. But with your server, when we connect via a WebSocket, we get:

[OPENSSL] 0xe13a968 SSL_connect: Handshake failed(1)!

But, when we connect directly using a SecureSocket, the handshaking works.

We'll have to investigate that a little more! Your server looks fine from what we can tell from an SSL check, we're trying to use TLS v1.3 for the connection.. and it shouldn't really be the case that a SecureSocket works from client code but not when it's run from within the builtin code!

Will check on this and if we can get past these issues, will send you an update build to test!

thanks

[JoseEstevesPt]

Thanks Andrew an update build sounds great! To test if my server is ok, i'm using Postman and all works well with the connections. Hope to ear from you soon :)

[ajwfrost]

Okay, the handshaking works when it's actually a connection on port 443. There's an omission in our detection code for the default port number so this had been trying to connect on port 80!

There is then the same issue that we had in the echo service with our code being too strict (i.e. not properly reading the specification..). The earlier issue I thought was related to garbage collection was actually just because we were debugging and there was a timeout happening behind the scenes!

So - will get a test build prepared for you for macOS..

thanks

[JoseEstevesPt]

Thanks once more, good news.

[ajwfrost]

Hi - please use the below link and then unzip that over the top of AIR 51 (it's built on top of 51.0.1.2 but shouldn't matter which 51.0.x.x version is under it...). This should

• ensure we have the correct port number used by default for secure websocket cases
• be more robust with the WebSocket protocol handshaking

https://transfer.harman.com/link/SYIfSjYLk7HDJbu6VuJ4u9

thanks

[JoseEstevesPt]

Andrew, thanks, you were really helpful. It seams to work now, later I will make more complex tests.

[raresn]

@JoseEstevesPt what are you using for the server? Thinking of implementing this in our app as well.

[JoseEstevesPt]

It's a linux web server, with node.js, express, ws, hope this was helpful.

[JoseEstevesPt]

Hello, some more issues...once more help needed. Everything runs fine in testing / development, but when I publish it to air, just won't install on a windows machine (yes I'm developing in mac but the production machine will be in windows). Tried to update AIR runtime to version version 50.2.4.1, with no success. I think the runtimes (51.0.1.1) you sent will only work on mac, correct? The project involves 2 apps (one air desktop windows and a second one running on android). My second problem is that due to missing files I can't compile to Android. Can you once more help? thank you in advance.

[ajwfrost]

For the first one -> we don't have an AIR shared runtime version 51.x yet. But will hopefully update that shortly!

For the second .. what's the SDK that you've got Animate pointed to? It seems strange for one of our SDKs to be missing that file, but strange for a non-Harman SDK to even be looking for it. So there may have been some issue with installation/deployment of the AIR SDK....?

If you have AIR SDK Manager open to the "Troubleshooting" tab, try building from Animate again, and see what the logs say..

[JoseEstevesPt]

Thanks for the fast reply. For the first issue, please define shortly, 1,2 days...or more?

For the second issue, I was able so solve the issue, and compile the APK, but it will not connect to the websocket, on the android tablet in production.

[ajwfrost]

Yes, one or two days should be about right - we had a slight issue with the macOS version that needs to be re-packaged..

If you've got issues with the Android connection: is that from the tablet, or to it? If the Android tablet is the client side then it may be challenging to sniff what's happening on the network (unless you are running the server?) but that would be my suggestion, so we can see the HTTP traffic and work out where the disconnection is coming. It may be best to try things in stages e.g. does it work on HTTP, before moving to HTTPS, and could you try the Android emulator before trying it on device, etc?

But I can also ask someone to try your test server from an Android handset here and see what happens...

[JoseEstevesPt]

I tried with two android tablets and could not connect, both can go online, and connect to webservices and download data, but can't connect to websocket server. I will wait for the next macOS version, and test it again.

[ajwfrost]

Ah - but yes I guess the updates that you need aren't in the Android runtimes yet... so I'd sent the macOS package but that only changed the macOS runtime, it didn't contain other updates.

What you'd need is the next 'full' release of AIR SDK with all the platforms updated.

The way things are going, that will be sooner rather than later - as soon as we've got a fix for the current arm64 JIT problems...

thanks

[JoseEstevesPt]

I think that will solve my problems... but now I have a time problem, next week i must have everything ready and working... will it happen?

[ajwfrost]

So the ideal scenario would probably be if we can find and fix the JIT thing in the next two days, then I'll trigger an update release to 51.0.1.3 with this stuff plus whatever other changes are in...

But to validate this websocket stuff, it would probably also be useful if I can send you an interim Android package that you can use to test it with! Otherwise we risk you finding a problem too last-minute to be able to change... I can kick that off fairly easily..

thanks

[JoseEstevesPt]

The interim Android package sounds just great, and I will be able to share any problems I encounter.

[JoseEstevesPt]

Thanks, later today I will test it.

[JoseEstevesPt]

hello, thanks for the files, just tried it...with no success, still can't connect to websocket on android. Works perfect on Mac, on Android on the debug I get Error #2031: Socket Error. URL: gr8events.tech

[ajwfrost]

FYI we seem to have a more fundamental issue with secure sockets on the latest Android versions. With some hacks, I can get the echo server to work, but I'm having to manually pass in a bunch of root certificates, ignoring an error code, and ignoring a CRL read failure. Will see if we can make this work a little better, we may need to have some other client-side workaround to avoid opening up some security holes in the short term...

thanks

[JoseEstevesPt]

I'm running out of time, can I expect a solution in short term? (2,3 days), will it work in non secure websocket? how can I help?

[ajwfrost]

It should work fine if it's not over a secure protocol ... something is up with SSL here, it won't be a particularly quick fix I'm afraid...

[JoseEstevesPt]

I've just tried using "ws://gr8events.tech:4117/" with no success, can connect with postman, with no problem. All works on mac, not on android...please help. We tested on a web server and on a local server.

[ajwfrost]

Can you double-check that port, I'm not getting any response when trying to connect a socket to 176.61.146.17:4117.. it retransmits after 1/2/4/8s and then gives up...

Transmission Control Protocol, Src Port: 54141, Dst Port: 4117, Seq: 0, Len: 0
    Source Port: 54141
    Destination Port: 4117
    [Stream index: 4]
    [Conversation completeness: Incomplete, SYN_SENT (1)]
    [TCP Segment Len: 0]
    Sequence Number: 0    (relative sequence number)
    Sequence Number (raw): 1763988296
    [Next Sequence Number: 1    (relative sequence number)]
    Acknowledgment Number: 0
    Acknowledgment number (raw): 0
    1000 .... = Header Length: 32 bytes (8)
    Flags: 0x002 (SYN)
    Window: 64240
    [Calculated window size: 64240]
    Checksum: 0x0422 [unverified]
    [Checksum Status: Unverified]
    Urgent Pointer: 0
    Options: (12 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted
    [Timestamps]

[JoseEstevesPt]

I just tested again with postman and works "ws://gr8events.tech:4117", but testing with your code on my mac it only works if I use"ws://gr8events.tech:4117/", it need the extra slash. When I publish to android it will not work, will not conencto to the server.