JavaScript, AJAX, Socket and Flash / ActionScript - explore the issue of data transfer in AJAX applications

As recently, I began to actively improve my skills and get acquainted not only and not so much with new technologies. For example, I have already more or less mastered Java, namely, I am engaged in network services. I also started working with ActionScript 3, although my opinion regarding the applicability of Flash components in AJAX applications has not changed - they should be used where they give the maximum advantage, but all the “binding”, for example, the user interface, can be done using standard technologies. When developing AJAX applications, the developer has a large enough choice for solving the problem of data exchange with the server. Basically, communication with the server is ...

• getting the initial data to form the page, this is usually done by the web server, since most applications are regular web pages. To do this, you can connect and application server, for example, PHP or any other, that is, the page can be both static and dynamic.
• getting data to work - for example, when the application has already loaded itself and everything you need, including graphics, styles and code, data is being requested, for example, a list of letters to be displayed in the mail client. For an application on ExtJS (however, any frameworks will do) usually data is loaded as JSON or XML, less often direct code loading is used (that is, the server generates HTML-code with JavaScript code included in the request and, optionally, JSON data). By the way, it is this approach that I use in many cases, it is very convenient - for example, if you have an interface with tabs (tabs), then you can generate a code for each tab at the time of the first call, and also update it, if necessary, with each visiting For example, this was the basis of my last game project, where all internal information blocks were formed in this way.
• Periodic data exchange (two-way) between the application and the server. For example, these are commands from the user and the result of processing by the server. This does not always require overloading the interface; I highlight here the flow of data and commands within the borders of one screen, while its state does not change. Here you can apply or directly download the code to a hidden item. That's exactly what I did in that game project - a request was periodically sent to the server, and a special DOM element was allocated for it, which was updated using the built-in UpdateManager mechanism from ExtJS (in more detail we already described its architecture and methods using the example of ExtJS 1.1 , and the material is still relevant, changes in the component are minimal when moving to other versions).

In addition to this fairly simple classification, I would like to raise another such question. In fact, to communicate with the server, we have, at the lowest level available with JavaScript, an XMLHTTPRequest object, which is adapted to transmit only string data via the HTTP protocol, as well as multiple bindings, wrappers and add-ins that hide implementation details, and providing a specific interface for specific needs. For example, in the same ExtJS, on this basis all interaction options are built - both Ext.Update and Ext.data.Proxy, although in the latter case everything is not so simple. Realizing the limited possibilities of XMLHTTPRequest for a long time (I think if you have development experience, then you know what limitations we are talking about), the developers have provided other options for interacting with the server, including exotic options via frames (for implementing long poll ). To overcome the cross-domain restrictions, there are ScriptTagProxy and others. But based only on the capabilities of the browser, HTML, and JavaScript is still very difficult to implement a fairly good, stable, and most importantly, productive and versatile communication system.

This question is expected to be solved radically in the HTML5 specification , where WebSocket will be provided, that is, the ability to get at its disposal and control through the usual JavaScript JavaScript capabilities of socket connections to the server. But when it will be ...

And this opportunity is needed now! Yes, it is the ability to replace access via XMLHTTPRequest (or rather, not replace, but supplement) with your own protocol, using the socket APIs standard for server systems, passing both string data and traditional text data through them.
')
The main difference is in the continuity of the transmission channel and its bidirectionality. That is, if in the traditional way we, in fact, initialize a new request each time, spending time on establishing a connection (and for HTTP this is quite expensive, there are nuances with the Keep-Alive property, but they have little effect on the overall picture). And the number of parallel requests from each browser is limited. And in many applications we need to establish a communication channel just after the start and keep it constantly open. This is where the module for implementing network sockets in JavaScript can help us.

To date, there are several options for implementing such a module, two of the most common:

• via JavaFX application or Java Applet, which will interact with your JavaScript module through the interface (and every technology that is designed to be embedded in web pages has it).
• through Flash, communication via the Extertnal Interface , by implementing an invisible Flash object.

Although in many ways technologically the path of interaction through Java / JavaFX seems to be more powerful, there are still many difficulties, although there are much more possibilities, including transferring partly the logic of a network application to an applet on the client side. However, there are a number of difficulties, for example, a long initialization time, but this seems to have been defeated in the new Java Applet architecture, as well as in security and cross domain policies (but this is everywhere, in any technology, since such a module is a potential security hole ). By the way, in the process of collecting information, I came across a description of the fact that the Java version does not require a policy file, but the jar file with the application must have a digital signature, and besides, it is impossible to secretly initialize the connection, it requires confirmation from the user. Both technologies allow both binary sockets to transmit binary data and text, but it should be noted that this appeared in Flash in recent versions, so below 9 (actually 8, but I'm not sure) may not work.

In general, the task is the following: a component is needed to implement a permanent connection to the server, while it is desirable to get rid of the HTTP protocol using a direct TCP / IP or UDP connection, as well as to be able to connect to any host and port. In addition, you must be able to implement your own protocol, transfer any data, both in text form, and possibly binary data, and the connection must be permanent, that is, after initialization, the socket remains open until the program or server closes forcibly or page reload. Well, the usual requirements - the minimum resource consumption of establishing and maintaining connections, cross-platform and cross-browser compatibility, the object interface and the ability to manage and intercept all significant events.

Fully these conditions, in my opinion, are satisfied by just a bunch of Flash - a small module in ActionScript, which implements a socket connection, and a wrapper on JavaScript, which controls the connection and receives / sends data. In Flash 9 and above, in addition to XMLSocket, we also have a lower-level I / O mechanism, which we will use, taking into account its greater versatility, as well as the ubiquitous distribution of the 9th version of Flash Player (and now 10 th)

One thing that still needs to be noted is that in order to communicate with a remote host, especially if it is not the same host from which the USB flash drive is loaded, it is also necessary if ports above 1024 are used (here I can be wrong, correct if anyone is in the subject), you must have on this host of the crossdomain.xml file, which describes the access policy (a good article on the topic ). Notice, not on the host from which we are connecting, but to which we are connecting! The policy file must be available on port 80, or another, 843. Certain difficulties may arise here if you have only your own socket server that serves another port, then for this you need to either raise the HTTP server additionally, or remake your own by adding listening on these ports.

Should I write such a component myself? In principle, if the required functionality is specific and you know Flash / ActionScript well, then the creation of such a module will take several hours, and as many more for writing and debugging a JavaScript wrapper for interaction. But it is worth looking, maybe there are ready-made solutions? And they are.

• Cometdesktop is the implementation of a whole web desktop, based on ExtJS, using the implementation of web sockets (even there are components for ExtJS right away), however the network subsystem is interesting enough for studying, but still it is a complex product, to our goals a little fit.
• Cumhurchat is more like an application for the implementation of a chat based on a network flash module, with a server on PHP, but so far the developers have not gone further. It's a pity.
• A good study of various options for the GWT technology, in particular, is considered and the server side. It is useful to read for exactly the theoretical part, to learn about the compatibility and difficulties in implementation.
• jssockets - this is exactly what we need. A very simple project, the API consists of several functions and events (because the interaction is asynchronous), allows you to establish a connection, write and read string data, and manage the connection. A minimum of documentation is offered, and the code should be taken from SVN, the flash module should be manually compiled. So I want something more developed ...
• jSocket - the best component to date for the implementation of network communication based on the Flash socket! I’m not afraid to call it the best, as it provides a full socket interface from Flash to JavaScript — any functions, for writing / reading any data types (strings, bytes, integers, floating-point numbers, even objects), notifies about all events, allows embed the module in any application. A feature of the library is the support of many independent connections - we can create new sockets without limit, the library holds a service array and each socket is unique (identified by id, although everything is implemented through the same SWF file). JQuery is used, but if you look at the source code, the library-dependent code there are only a few lines, so you can rewrite it, if necessary, under another framework.

There is one nuance in jSocket - the library is still in the alpha version stage, although it is fully operational, the 1.0 release version is also planned. It is best to take a non-accessible compiled version, and go to the SVN repository and get the source code from there. Unfortunately, the author took the position that once alpha, it means no guarantees and help, except for the available description of the API and one example (I knocked him in GTalk, but that was the answer). By the way, if you need, in SVN you will find the simplest network server in Java, which can be paired with jSocket. I, for example, implemented my own xSocket based framework (Java NIO framework), and in the client part I used ExtJS together with the jQuery adapter, in this configuration the library worked without problems. The API is fairly simple, only one page describes the functions, and the example covers the typical use of the library, so this material will be enough for you to get to know, and in the future I will try to write my manual, there is something left to do on the server side so that you can create your own protocols exchange based on strings.

And the result of this study is simple. For serious AJAX applications, if you have several points in the client architecture that request data and they require constant updating, or their frequency is relatively small, the option with several connections via XMLHTTPRequest (or add-ins available in third-party frameworks) can become a bottleneck .

Here's an example: in the online game that we did, we had, at best, 3 requests for updates, which worked periodically - in order to avoid performance problems, we had to sacrifice the update speed, literally manually setting the update time intervals (like Now I remember, for the chat there was 3 seconds to update the list of messages or on the fact of sending yours, for the list online was 7 seconds, a periodic heartbeat request that updates the player’s status and receives some more data, worked every 15 seconds ND). Still, such a scheme, especially if user actions that also generate requests are superimposed on it, does not start to work in the best way.

Therefore, it is worth seriously considering the possibility of using a socket connection and a special server if you need fast response and data processing.

Regarding the server - while the best option is a server in Java, since PHP, due to its session nature, will bring almost no benefits to all, and a properly designed Java server can serve thousands of simultaneous connections. If this path is interesting for you, look at another project found in the depths of the Google Code - GFS Server - an open source server for Flash and Flex clients. As part of our project to create an open gaming platform, we will soon lay out the implementation of our own server (Java, based on the JBoss Netty framework), as well as a simplified version of the client script based on jSocket, but rewritten to use ExtJS, without the need for third-party libraries, and Let's share one of the protocol options on top of this bundle.