Skip to main content
Inspiring
February 22, 2011
Answered

Adobe Air ServerSocket not Working the same on XP/Vista/7

  • February 22, 2011
  • 1 reply
  • 3665 views

I'm having a strange problems with an air socket server i've written.

I have an Air application written using Flash Builder 4.  It's basically a simple HTTP server.  It's purpose it to open a server on a specific port and serve files (both html and swf) out to a web browser.

When i run the air application on my desktop (windows 7, firefox 4.0b11, ie8, flash builder 4 compiled with flex sck 4.1.0) everything works correctly.  Whether i run the server through the Flash Builder debugger or actually do the full packaging and install as a standalone air app then run it using the Air Runtime like any user would.  I load up the server, punch in the address from anywhere and the page loads, and the requested swf displays correctly.  While the server is running on my desktop i've tested clients including Windows XP and Vista with IE8, HTC Evo4g Android phone, and the Playstation 3 browser.  From any tested client with the server running on my desktop all requests are handled correctly and pages/swfs load and display correctly.

The problem comes when i run the air app on another computer.  When i package it and install it on one of my two test systems (Windows XP and Windows Vista) things start to go wonky.  The Air app loads on the two test systems but when a client tries to use their web browser to request a page things don't display correctly.  The client can load the html file fine but the swf that it receives from the server does not display.  I can check the log on the status server and see the HTTP GET being processed, and the file sent.  However, the browser simply displays a blank box where the SWF should be.  With the server running on either of my two test boxes (XP and Vista) the same clients who can connect and display html and swf's delivered from the server experience this problem.

I think i've eliminated browser request as the problem from testing different browsers on different OS's on each of the test installations.  As best I can tell, the problem is with the server side of the app.  The server uses the SocketServer class to listen for a connection and then writes out the HTML headers and content to the socket manually, i'm not using any external libraries for writing to the socket.

here's the code for writing to the socket when a swf is requested.

{

     var content:ByteArray = new ByteArray();

     var stream:FileStream = new FileStream();
     stream.open(file, FileMode.READ);
     stream.readBytes(content);
     stream.close();

     socket.writeUTFBytes("HTTP/1.1 200 OK\n");
     socket.writeUTFBytes("Content-Type: application/x-shockwave-flash\r\n");
     socket.writeUTFBytes("Content-Length: " + content.length + "\r\n\r\n");
     socket.writeBytes(content);

}

I don't believe the problem is with the socket write since it works on my desktop but not when the server is running on another.  I'm wondering if the problem is with an external system dependancy.  Are there any external libraries, visual c++ runtimes, tcp/ip libraries that Air uses to fulfil requests to sockets on different operating systems/versions?  I've been searching around the web and browsing through adobe live docs for a few hours on this but can't seem to find a resolution anywhere.  If more detail is needed, please let me know.  Any help would be much appreciated.

This topic has been closed for replies.
Correct answer chris.campbell

Removing the socket.close() seems to have fixed it.  Now all of the file is being transmitted on all of my machines.

I appreciate your help and will work on another solution for closing the socket.  Can't really do a flat timer to handle closing the socket in my situation since it will take varying amounts of time to send files depending on size and client speed.

It's not the most elegant of solutions but I may just have the client send a message to the server to notify that it finished receiving the data so the original socket can be closed.


Hi Tim,

I was going to suggest doing just that, having the client send back a message that the load was complete.  I know this isn't optimal, but unfortunately there isn't a better solution right now. We're aware that this is lacking and we are working on a solution for an upcoming release.  You can track this bug at http://bugs.adobe.com/jira/browse/FP-6

Thanks,

Chris

1 reply

chris.campbell
Legend
March 1, 2011

Hi,

Could you try adding "socket.flush()" to your code?

Here's a blurb from the docs:

On some operating systems, flush() is called automatically between execution frames, but on other operating systems, such as Windows, the data is never sent unless you callflush() explicitly. To ensure your application behaves reliably across all operating systems, it is a good practice to call the flush() method after writing each message (or related group of data) to the socket.

Thanks,

Chris

Inspiring
March 1, 2011

I am calling socket.flush() and socket.close() after writing the necessary data to the socket.

I'm sorry for not including that.

HTML files sent over the socket display correctly.  SWF files do not.  They display an empty box where the SWF should be.  I'm looking into the headers i'm sending to see if maybe the Content-Length is being misreported and maybe this is causing the SWF preloader to not go off correctly.

chris.campbell
Legend
March 1, 2011

Hi Tim,

Thanks for responding back.  Would it be possible to get a sample project/app that illustrates the problem?  Please feel free to contact me directly at ccampbel@adobe.com.

Thanks,

Chris