Flash and XML[c] A Developer[ap]s Guide

Among the exciting possibilities of XMLSockets in Flash is that, with the right server code, two or more clients can connect to the same server at the same time and communicate fairly directly with one another. Chat is the obvious and ever-popular use of this technology. Head-to-head games are another exciting use. Certainly the combination of Flash's multimedia and direct human contact will be exploited in other ways, some fun and some professional. The latter can include distance learning and customer service applications, for example.

To transform our simple echo server and its client into an experimental chat system, we don't have to do much. The client, in fact, could stay the same, but it would be fairly confusing, since it has an extremely limited one-line display. We update it into a multiline scrolling record. In fact, we keep a record of both outgoing and incoming traffic. This is more than most chat designers would want, but it is useful as we experiment and debug.

The minimal upgrade of the server requires us to log in multiple users simultaneously and to share messages among them. A commercial chat system can add a lot of value by controlling the flow of chat messages to develop certain social structures. We create a simple any-to-all model.

The result we are trying to achieve is communication between clients. Though the server is essential-enabling technology, it is meant to be as transparent as possible. We want the clients simply to be aware of one another.

The architecture that best describes this communication is peer-to-peer connection. Serverless symmetry is the goal of many chat designers, game designers, and copyright-busting file-sharing systems.

While we want the feel of peering, we quickly find (as have many others) that in the practical world, it is best achieved through an invisible server. In our case, there are many obstacles. First the domain perimeter model keeps Flash from contacting any server other than at its home domain. With some inconvenience we could employ workarounds.

More intractable is the fact that Flash simply cannot provide the server side of a socket. The operating system, the user 's connection provider, and the stability of the IP address all pose big problems further down the line. But we don't have to face these problems since Flash stops us first.

So we go forward with a server-centered system.