Flash sockets in chat

I hear a lot about people using flash sockets in chat and other long polling开发者_StackOverflow社区 apps.

Why is flash used in these scenarios?

---

Performance, because Flash provides the developer with Sockets. Using Sockets, you can open a connection and keep it open until the client leaves the app. When there is new info in the server, it writes the data in the communication channel and the clients automatically reads it. No pulling, no connection overhead, no extra data needed (HTTP protocol header, for instance).

The network latency and bandwidth will limit the amount of data your server can send. It will also limit the amount of data your client can read. Regarding the server, the amount of resources (generally RAM memory) limits the number of active connections (concurrently open) you are allowed to keep.

When HTTP is used for a chat (or another long polling) app, the communication is stateless, which mean the app must open a new connection with the server every time it has to exchange data. You can use persistent connection (Keep-Alive) to reuse an existing connection, but depending on the timeout, it will hurt server performance:

• High timeout value: more data exchanged using a single connection, but it will tie up multiple server processes or threads for too long. The server will support fewer users concurrently.

• Low timeout value: server processes are released quickly to serve another request because they drop your connection earlier, however if the timeout is too low you will end up not reusing the connection, which leads to a new connection every time you must exchange data. Very bad.

Additionally the HTTP protocol was not designed for real-time communication. It requires text based headers that will waste a precious amount of bytes when communicating. I wrote an article comparing different communication protocols for Smartfox Server and I noticed that in text based protocols (XML, JSON) the header (and complements) represented 50-75% of the message size in my case; even though the message "pure" data was very small (28 bytes), it gives an idea of header overhead.

If you keep a channel open during the whole communication time and exchange data in binary form, you avoid connection overhead and can tweak the messages to achieve great throughput.

NOTICE: today you can use WebSockets to achieve results that were possible only with Flash communication in the past. Socket.io, for instance, enables realtime connectivity on every browser using javascript; under the hood it uses WebSockets (when available), or Flash, or AJAX or other technique supported by the browser to make the communication.

---

The API allowing plain TCP connection aren't universally available to JavaScript (those would be WebSocket API). Some browsers don't have them yet. When you say long polling you probably mean the technique used to imitate plain TCP over HTTP (an absurdity of a kind :)). That is an HTTP request that takes enormous time to send, but is being sent in chunks. This technique is rather a misuse of HTTP, but is nevertheless popular because we have limited alternatives when it comes to web development.

Of course you could use any other browser plugin or any other standalone application that implements TCP for a chat program.

You could certainly design a chat program that works over HTTP, but due to the stateless nature of HTTP it would make tasks as session maintenance more difficult and less efficient (as you'd be required to send the session information over and over again with each request).

Finally, several popular IM formats (such as Jabber for example) require TCP connection. Jabber also requires that you Base64-encode the contents (however silly that is, it's a format a lot of people use...) and use some encryption algorithm for authentication. Flash is faster when working with binary data then JavaScript / it's easier to implement encryption algorithm there.