Socket connections allow the Flash Player to send and load data from a server over a specified network port. The main difference between socket and server connections is that socket connections don’t automatically close after data transfer is complete.

When a socket connection is made, the connection stays open until the client (the Flash Player) or the server explicitly closes it. Because of this, sockets enable a special type of communication called data push, which means that the server sends information to the Flash Player at any time without a request coming from the Player itself.

Socket connections are typically used to create multiuser applications. An example of one such application would be an online chat room. The chat program might consist of a central chat server with various connected Flash Player clients. Each time a client .swf sends a message to the server, the server determines which client should receive the message and pushes the message to that specific client over the open connection. In this case, the receiving client didn’t ask for the message, but rather the message was simply pushed out to it by the server. When a client closes a connection, the server notifies the other clients that someone has logged off of the system.

Two types of socket connections can be made from the Flash Player to a socket server. They are very similar in behavior and operation, but have a few subtle differences. The first is an XML socket connection that is similar to the XMLSocket in previous versions of the Flash Player. New for Flash Player 9 is a binary socket connection.

To create an XML socket connection, use the flash.net.XMLSocket class. To create a binary socket connection, use the flash.net.Socket class.

XML socket connections are focused around text. The client and server communicate by exchanging XML packets containing data. Actions are carried out by analyzing the contents of the XML packets.

Binary socket connections are new in ActionScript 3.0 and enable raw connections that allow for transfer of binary information. Binary sockets are slightly more advanced than XML sockets because they require a low-level knowledge of binary datatypes, but they are also more powerful because you can connect to a wider range of socket servers and generally do more with them. For example, binary sockets allow you to connect to mail servers (via POP3, SMTP, and IMAP), news servers (via NNTP), chat servers, or even implement screen sharing and remote desktop applications by connection to a VNC server (via RFB).

Regardless of which socket connection type you use, the connection behaves in an asynchronous manner. This means that you can’t read data from the socket connection until you have been notified that data is available via an event handler. All data reading must be done in an event handler that executes automatically when data is available. Synchronous socket connections, when attempting to read data from the socket causes your program to wait until data becomes available in the socket, are easier to program but not as efficient. You’ll learn more about how to deal with the asynchronous nature of the Flash Players socket connections as you go through this chapter.

Connecting to a Socket Server

Problem

You want to establish a connection with a socket server.

Solution

Use either the Socket.connect( ) or XMLSocket.connect( ) method and listen for the connect event to be notified when a connection is made.

Discussion

To connect to a socket server, there are two critical pieces of information that you need to know before attempting to make a connection. The first is the domain name or IP address of the server to which the connection will be made, and the second is the port over which the connection should take place.

Whether you are using a Socket or an XMLSocket instance, the connection process is exactly the same; both classes define a connect( ) method that takes two parameters:

host

A string value specifying the host to connect to, either with a domain name such as www.example.com, or with an IP address such as 192.168.1.101. To connect to the web server the Flash movie is being served from, pass null instead of a string hostname.

port

An int value specifying the port number that should be used to connect to the host. The port value must be at least 1024, unless the server has a policy file specifically allowing ports less than 1024.

Because of the asynchronous nature of socket programming in Flash, the connect( ) method does not wait for a connection to happen before continuing to the next line of ActionScript code. If you try to interact with a socket before a connection has been fully established, you’ll encounter unexpected results and your code won’t work correctly.

The proper way to connect to a socket is to first add an event listener for the connect event before attempting to call connect( ). The connect event is dispatched by both Socket and XMLSocket objects when a successful connection has been made, letting you know that the socket is ready to be interacted with.

The code for connecting a Socket instance to a socket server running on localhost over port 2900 looks like this:

package {
  import flash.display.Sprite;
  import flash.events.*;
  import flash.net.Socket;

  public class SocketExample extends Sprite {

    private var socket:Socket;

    public function SocketExample(  ) {
      socket = new Socket(  );

      // Add an event listener to be notified when the connection
      // is made
      socket.addEventListener( Event.CONNECT, onConnect );

      // Connect to the server
      socket.connect( "localhost", 2900 );
    }

    private function onConnect( event:Event ):void {
      trace( "The socket is now connected..." );
    }

  }
}

If you want to connect via XMLSocket instead, the code is almost exactly the same. First, you create the event listener for the connect event, and then you invoke the connect( ) method. The only difference is that all Socket references should be replaced with XMLSocket:

package {
  import flash.display.Sprite;
  import flash.events.*;
  import flash.net.XMLSocket;

  public class SocketExample extends Sprite {

    private var socket:XMLSocket;

    public function SocketExample(  ) {
      socket = new XMLSocket(  );

      // Add an event listener to be notified when the connection is made
      socket.addEventListener( Event.CONNECT, onConnect );

      // Connect to the server
      socket.connect( "localhost", 2900 );
    }

    private function onConnect( event:Event ):void {
      trace( "The xml socket is now connected..." );
    }

  }
}

If the connection fails, one of two things can happen: either the connection fails right away and a runtime error is generated, or an ioError or securityError event is raised to indicate that the connection could not be completed successfully.

Remember, when connecting to a host with a socket connection, the following Flash Player security sandbox rules apply:

Violating the security sandbox by attempting to connect to an untrusted domain or on a low port raises a securityError event. These issues can both be worked around by using a cross-domain policy file. To use a cross-domain policy file with either a Socket or XMLSocket object, you need to load the policy file by using flash.system.Security.loadPolicyFile( ), as shown here:

Security.loadPolicyFile("http://www.rightactionscript.com/crossdomain.xml");

When assembling the cross-domain policy file, you should specify not only the allowed domains, but also the allowed ports. If you do not specify allowed ports, Flash Player assumes that port 80 (standard HTTP port) is the only allowed port. You can specify a comma-delimited list using the port attribute of the <allow-access-from> tag. The following policy file allows all domains to connect to ports 80 and 110 (standard HTTP and POP mail ports):

<?xml version="1.0"?>

<!DOCTYPE cross-domain-policy SYSTEM "http://www.macromedia.com/xml/dtds/cross-domain-policy.dtd">
<cross-domain-policy>
   <allow-access-from domain="*" to-ports="80,110" />
</cross-domain-policy>

Sending Data

Problem

You want to send data to a socket server.

Solution

For Socket objects, use the write methods (writeByte( ), writeUTFBytes( ), etc.) to write the data to the buffer and call flush( ) to send the data. For XMLSocket objects, use the send( ) method.

Discussion

The Socket and XMLSocket classes define different APIs for sending data to the socket server. Let’s look at the Socket API first.

When you want to send data to a socket server using a Socket object, you first must write the data to the buffer. The Socket class defines a slew of methods for writing data. Each of the methods writes a different type of data (or writes the data differently). The methods are writeBoolean( ), writeByte( ), writeBytes( ), writeDouble( ), writeFloat( ), writeInt( ), writeMultiByte( ), writeObject( ), writeShort( ), write- UnsignedInt( ), writeUTF( ), and writeUTFBytes( ). Most of the methods accept one parameter of the type implied by the name of the method. For example, writeBoolean( ) accepts a Boolean parameter and writeByte( ), writeDouble( ), writeFloat( ), writeInt( ), writeShort( ), and writeUnsignedInt( ) accept numeric parameters. The writeObject( ) method accepts an object parameter that must be serializable to AMF format. The writeBytes( ) method allows you to pass it a ByteArray parameter along with offset and length parameters. For example, the following calls writeBytes( ) passing, it a reference to a ByteArray object and specifying that it should write all the bytes (starting at offset 0 with length equal to the length of the ByteArray):

socket.writeBytes(byteArray, 0, byteArray.length);

The writeUTF( ) and writeUTFBytes( ) methods allow you to write strings. Each method accepts a string parameter. The writeUTFBytes( ) method simply writes the string as bytes. The writeUTF( ) method first writes the number of bytes before writing the actual byte data.

The writeMultiByte( ) method also writes string data, but using a nondefault character set. The method requires two parameters: the string to write and the name of the character set to use. The help documentation for Flash and Flex list the supported character sets along with the labels and aliases for each. Use the label value as a string when specifying the character set for writeMultiByte( ). The following example writes a string example using Unicode:

socket.writeMultiByte("example", "unicode");

Which method or methods you use to write data to a Socket object is entirely dependent on what sort of data you want to write and what sort of data the server expects. Using a Socket object, you can write a Telnet or POP mail client entirely by using ActionScript. Both protocols expect ASCII text commands. For example, after connecting to a POP server, you can specify a user with the USER command. The following writes such a command to a Socket object:

// POP servers expect a newline (\n) to execute the preceding command.
socket.writeUTFBytes("USER exampleUsername\n");

Writing the data to the Socket object does not actually send the data to the socket server. Each call to a write method appends the data to the Socket object. For example, the following writes four bytes to a Socket object, but none of them are sent:

socket.writeByte(1);
socket.writeByte(5);
socket.writeByte(4);
socket.writeByte(8);

When you want to send the accumulated data to the socket server, use the flush( ) method. The flush( ) method simply sends all the written data and clears the buffer:

socket.flush(  );

The XMLSocket class has a much simpler API for sending data. Writing and sending data occur with one method aptly named send( ). The send( ) method accepts parameter of any datatype. It converts the parameter to a string and sends it to the server. Traditionally the parameter is an XML object or a string containing data structured as XML:

xmlSocket.send(xml);

However, the exact format of the data is entirely dependent on the format the server expects. If the server expects XML-formatted data, then you’ll need to send XML-formatted data. If the server expects URL-encoded data, then you’ll need to send URL-encoded data.

Receiving Data

Problem

You want to read data from a socket server.

Solution

For Socket instances, subscribe to the socketData event and invoke one of the read methods, such as readByte( ) or readInt( ), in the event handler, making sure not to read past bytesAvailable.

For XMLSocket instances, subscribe to the data event and interpret the XML data received inside of the event handler.

Discussion

Receiving data from a socket connection depends on the type of socket you use. Both Socket and XMLSocket are capable of receiving data from a server, but they do so using slightly different techniques. Let’s focus on how the Socket class works first before discussing XMLSocket.

As you’ve learned in the introduction to this chapter, sockets in Flash behave asynchronously. Therefore, it’s not possible to simply create a socket connection and attempt to read data from the socket right away. The read methods don’t wait for data to be transferred from the server before returning. Instead, you can only read data from a socket after the client has already downloaded the data from the host server. It is an error to try and read data from a Socket before any data is available.

To know when data is available to be read, the socketData event is broadcasted from Socket instances. By adding an event listener for the socketData event, your event handler is invoked anytime there is new data received from the socket server. Inside the event handler is where you write code to read and interpret the received data.

To read the data sent from the server, the Socket class provides a number of different read methods, depending on the type of data you want to read. For instance, you can read a byte with the readByte( ) method, or read an unsigned integer with the readUnsignedInt( ) method.

Handshaking with a Socket Server

Problem

You want to do handshaking with a socket server and need to know what the received data’s context is to know how to process it.

Solution

Create different constant variables to represent states of the protocol. Use the constants to map particular processing functions with the corresponding state. In a socketData event handler, call the appropriate function by invoking it through the state map.

Discussion

A common scenario when connecting to a socket is going through a handshake process. Typically, the server initially sends data to the client. The client then responds to the data in a particular manner, and the server responds again accordingly. This entire process repeats until the handshaking is complete and a “normal” connection is established.

It gets difficult to process the response from the server because the socketData event handler does not keep track of context. That is, there is no “why” sent along with the server response, or no “this data is in response to” processing directive. Knowing how to process the response from the server is not usually something that can be gathered through the response itself, especially when the response varies. Perhaps one response returns two bytes and another returns an integer followed by a double. You can begin to see how this presents itself as a problem.

The solution is to create various state constants to represent the different contexts in which the server sends data to the client. By associating each of these constants with a particular function to handle the data, you can easily call the correct processing function based on the current state of the protocol.

Consider the following handshaking scenario that happens when you connect to a socket server:

In reality, Step 4 involves a more secure response to an authentication challenge. Instead of just sending back the challenge verbatim, you would really want to use some sort of encryption with a user-supplied key. Perhaps the client asks the user for a password, and then the password entered is used as the encryption key for the 8-byte challenge. The encrypted challenge is then sent back to the server. If this challenge response matches what the server expected, then the client knew the right password and the connection should be allowed.

To implement the handshaking processed outlined, you first want to create constants to represent the different kinds of data returned from the server. First, there is determining the version from Step 1. Second, there is receiving the challenge from Step 3. Finally, there is the normal operating mode from Step 5. These can be represented by the following constants:

public const DETERMINE_VERSION:int = 0;
public const RECEIVE_CHALLENGE:int = 1;
public const NORMAL:int = 2;

It doesn’t matter what values are given to the constants. Rather, the only important part is that all the values are different so no two constants represent the same int value.

The next step is to create different functions to process the data. The three functions created will be named readVersion( ), readChallenge( ), and readNormalProtocol( ). After the functions have been defined, a map must be created to associate one of the previous state constants with the function used to process the data received during that state. The code for that looks like this:

stateMap = new Object(  );
stateMap[ DETERMINE_VERSION ] = readVersion;
stateMap[ RECEIVE_CHALLENGE ] = readChallenge;
stateMap[ NORMAL            ] = readNormalProtocol;

The final step is to code the socketData event handler in such a way that the correct processing function is invoked based on the current state of the protocol. To do this, a currentState int variable is created. Then, using the stateMap, the processing function is invoked by looking up the function associated with currentState:

var processFunc:Function = stateMap[ currentState ];
processFunc(  ); // Invoke the appropriate processing function

There is a little bit of bookkeeping involved in this process. Be sure to update currentState in your code to accurately reflect the current state of the protocol.

The entire code example to process the handshaking scenario previously described looks like the following:

package {
  import flash.display.Sprite;
  import flash.events.ProgressEvent;
  import flash.net.Socket;
  import flash.utils.ByteArray;

  public class SocketExample extends Sprite {

    // The state constants to describe the protocol
    public const DETERMINE_VERSION:int = 0;
    public const RECEIVE_CHALLENGE:int = 1;
    public const NORMAL:int = 2;

    // Maps a state to a processing function
    private var stateMap:Object;

    // Keeps track of the current protocol state
    private var currentState:int;

    private var socket:Socket;

    public function SocketExample(  ) {
      // Initialzes the states map
      stateMap = new Object(  );
      stateMap[ DETERMINE_VERSION ] = readVersion;
      stateMap[ RECEIVE_CHALLENGE ] = readChallenge;
      stateMap[ NORMAL            ] = readNormalProtocol;

      // Initialze the current state
      currentState = DETERMINE_VERSION;

      // Create and connect the socket
      socket = new Socket(  );
      socket.addEventListener( ProgressEvent.SOCKET_DATA, onSocketData );
      socket.connect( "localhost", 2900 );
    }

    private function onSocketData( event:ProgressEvent ):void {
      // Look up the processing function based on the current state
      var processFunc:Function = stateMap[ currentState ];
      processFunc(  );
    }

    private function readVersion(  ):void {
      // Step 1 - read the version from the server
      var version:int = socket.readInt(  );

      // Once the version is read, the next state is receiving
      // the challenge from the server
      currentState = RECEIVE_CHALLENGE;

      // Step 2 - write the version back to the server
      socket.writeInt( version );
      socket.flush(  );
    }

    private function readChallenge(  ):void {
      // Step 3 - read the 8 byte challenge into a byte array
      var bytes:ByteArray = new ByteArray(  );
      socket.readBytes( bytes, 0, 8 );

      // After the challenge is received, the next state is
      // the normal protocol operation
      currentState = NORMAL;

      // Step 4 - write the bytes back to the server
      socket.writeBytes( bytes );
      socket.flush(  );
    }

    private function readNormalProtocol(  ):void {
      // Step 5 - process the normal socket messages here now that
      // that handshaking process is complete
    }
  }
}

Disconnecting from a Socket Server

Problem

You want to disconnect from a socket server, or be notified when the server disconnects you.

Solution

Invoke the Socket.close( ) or XMLSocket.close( ) method to explicitly close the connection, or listen for the close event to be notified when the server closes the connection for you.

Discussion

A general rule to follow when programming is to clean up after yourself. That is, if you create an object, you should also delete it when it is no longer necessary. In this case, whenever you connect to a socket server, you should explicitly close the connection when you’re done. Leaving an unused socket connection open is a waste of resources and should be avoided if at all possible. If you don’t close a connection, then the server may continue to keep an open socket connection that is not being used, which can quickly cause a server to overrun its allotment of allowed socket connections.

Closing a socket connection is the same for both Socket and XMLSocket instances. All you need to do is invoke the close( ) method on the socket instance:

// Assume socket is a connected Socket instance
socket.close(  );  // Disconnect from the server

Using an XMLSocket is exactly the same:

// Assume xmlSocket is a connected XMLSocket instance
xmlSocket.close(  );  // Disconnect from the server

The close( ) method is useful for letting the server know that the client wants to disconnect. To be notified when the server closes the connection on its own, you should listen for the close event by calling addEventListener( ) on the Socket or XMLSocket instance with Event.CLOSE as the event type; for example:

var socket:Socket = new Socket(  );

// Add an event listener to be notified when the server disconnects
// the client
socket.addEventListener( Event.CLOSE, onClose );

Invoking the close( ) method does not raise the close event. Instead, the close event is raised only when the server initiates the disconnection.

Once a socket is closed, it is no longer capable of reading or writing data. If
you'd like to reuse the socket, you have to establish a connection again.

Handling Socket Errors

Problem

You want to handle errors that might occur when using sockets.

Solution

Use try/catch to handle I/O and end of file (EOF) errors.

Discussion

Both the Socket and XMLSocket classes behave similarly in regard to errors and error events. When calling the connect( ) method, Socket and XMLSocket objects can throw an error of type SecurityError when either of the following conditions is true:

• The .swf is classified as local untrusted.

• The port number is higher than 655535.

When calling send( ) (XMLSocket) or flush( ) (Socket), the method can throw an error of type IOError if the socket isn’t connected. Although you can (and likely should) place the send( ) or flush( ) method calls within try/catch blocks, you should not rely on try/catch blocks as part of your application logic. Rather, use an if statement to test whether or not the socket object’s connected property is true before calling send( ) of flush( ) if you want such a test to be part of the application logic. For example, the following uses an if statement as part of the application logic to call a connectToSocketServer( ) method if the Socket object isn’t currently connected. It also uses a TRy/catch block to write to a log if the flush( ) method throws an error:

if ( socket.connected ) { try { socket.flush( ); } catch( error:IOError ) { logInstance.write( “socket.flush error\n” + error ); } } else { connectToSocketServer( ); }

All of the Socket read methods can throw errors of type EOFError and IOError. EOF errors occur when you try to read data, but nothing is available. I/O errors occur when you try to read from a socket that is closed.

In addition to the errors thrown by methods of the Socket and XMLSocket classes, objects of those classes also dispatch error events. There are two basic types of error events that occur with socketsIOError and securityError. The IOError event is of type IOErrorEvent, and it occurs when data fails to send or load. The securityError event is of type SecurityErrorEvent, and it occurs when a socket attempts to connect to a server but fails because the server is either outside of the sandbox or because the port number is lower than 1024.

Both security error event scenarios are correctable by way of a cross-domain policy file.

From ActionScript 3.0 Cookbook (The best!)

SWF DESKTOP
A tool that will let you use SWF files as a desktop background.
JPEGs? Tired. Flash MX? Wired!” That is the slogan for this product. Extremely easy to use as their screensaver tool ScreenTime but with just enough features. The program relies on Flash MX for any advanced functions, but just imagine the possibilities. Now you can make desktops that are even more pretty and useless than before, but you can also make smart desktops that keep you updated on news (did I hear someone say RSS-reader?) or include direct access to the company’s addressbook applications.
http://www.screentime.com/

Swiff Player
Cool standalone player supporting hardware acceleration og both playback and some FX. FX include play as colored/black outlines, 3D Plane, 3D Slices (1 slice per layer in the SWF, fully rotatable!) and 3D Cube, plus “play as fast as possible”
GlobFX

Power Resolut
Not a standalone player, but a hardware accelerated ActiveX plugin. Have your SWF files swap resolution of the users screen when they enter an enabled SWF file for increased playback speed. Based on the FullScreen player.

Here’s a couple of tricks we use on a daily basis to keep things running smooth. Nothing fancy or complicated, but guaranteed success.

UPDATE: Tera at trick7 posted a Japanese translation for our fine friends on the other side of the Pacific. We think that’s pretty cool. Check it out here.

Masks Are Bad
Well, they’re not all bad. Masks can be exceptionally useful, as we all know by now. They’re the #1 performance killer though. When you mask something, you force the player to decide what needs to be rendered and hidden every single frame. So how do you get around without masks? With a little bit of patience and tricky layering (such as making the background the foreground with a giant hole cut out for where your viewable area is) you’ll be able to get the same end result without the performance hit.

Alpha PNGs and Video
Same deal as the masks. Sometimes its unavoidable, but you’re still asking the player to figure out what to render under the alpha. Sometimes we’ll make an alpha video at half size and then scale it in Flash. You’d be surprised how good it still looks.

Oh, and with regards to alpha video: Try experimenting with PNG sequences in place of the alpha video. Video usually performs a little better, but its always worth looking into.

Frame Rate
Despite all discussions otherwise, there is no magic framerate. We use 25 or 30 because (as far as I know) we like it best. At some point we tested and determined one was slightly better than the other, but generally speaking this is not going to be the primary cause of a site running slow. I wouldn’t generally advise going higher than 30 though, just because you’re asking the player to render an awful lot awfully fast…

cacheAsBitmap and BitmapData
Where possible use cacheAsBitmap to rasterize vector items. You’ll force Flash to draw the symbol one time and then never again. On the flip side, if you’re scaling or rotating a symbol NEVER set it to cacheAsBitmap. Then you force Flash to render AND recapture the raster every frame, making the process slower instead of faster.

With sites like the Da Vinci Code and Nike Air, we would take a dynamic screenshot of the section, draw it into an empty movieclip and then manipulate the screenshot to animate it out. This is far, far faster than animating many elements out, or animating over top of many elements. I highly recommend this practice.

_visible is better than _alpha
_alpha = 0 and _visible = false are totally different things. Alpha determines the opacity of a clip. Visible determines whether or not the clip should actually be rendered by the player. If you’re setting something all the way invisible, use the _visible property.

onEnterFrame and setInterval
When you’re through with these processes, clear them from memory with onEnterFrame = null; and clearInterval(myInterval); respectively. Leaving these around when you’re not using them is like leaving the telephone off the hook when you’re done with a call.

Pre-define your math
Got a sine wave you’re about to draw? Is it the same sine wave every time? Hard code the numbers into an array. By doing the math for Flash, you’re saving some complex processes in advance. I even experiment with using a Tween that I nextFrame() thru to get all of the entries into an array before hand.

Silent Sound
We use this as a last resort, but its a trick worth mentioning. By putting a silent sound file on a seperate layer for the duration of your timeline, setting it to stream and looping it, the player will automatically drop frames to keep up with the sound.

Got any other good ones? I’m sure I didn’t list them all here

From: Bigspaceship