Flash's ExternalInterface and dynamic loading
So I coded my very simple and invisible SWF, which only exports an interface to XMLSocket that I can use from JS. I learned a few things and thought I'd write about my experiences here (before you flame my genuine lack of Flash knowledge, please understand that it's the second time in my life when I touch Flash and all I wanted was to get out of that IDE ASAP :D I hate it.).
External interface doesn't work if your applet is really invisible.
Or at least, that's my conclusion. If I put width="0" and height="0" on the <embed> and <object> tags, bye bye ExternalInterface. In fact, bye bye Flash—nothing seemed to work.
So I had to resort on adding width="1" and height="1". After this hack, everything worked fine in all but the most problematic browser of All Time (InternetExplorer).
External interface doesn't work in Internet Explorer unless you're loading the SWF during page load.
I spent all day debugging this in Internet Explorer (while Firefox and Safari were doing just fine; I'm not sure about Opera yet).
In order to make it work in IE while still not loading the SWF from the start, I had to create an IFRAME where I loaded the SWF—this time it registers the ExternalInterface alright. I also couldn't play with making the IFRAME invisible (i.e. width=0, or display: none) — that won't work, you have to hide it differently (by i.e. positioning it outside the viewable area).
Back to basics
Isn't “old school” great? I don't want to use Flash, but I have to because by default, browsers don't have anything that would allow me to open an arbitrary TCP connection. Why? The things you can do with XMLSocket are amazing—like, being connected to the server.
Some folks have imagined ingenious ways (Comet) to do this with existing infrastructure: because HTTP is a request/response-based protocol, it means that the server can't tell something to the browser unless the browser has requested that something. So the nifty idea was to make an XMLHttpRequest (yay, AJAX!) from the browser, request that the server would not respond until it has something to say. Like “incoming move from your opponent” in a multiplayer game. That is called a “long lived” request, since the socket is open and the client waits for information, which the server will eventually send. This looks pretty much the same as the good old select() to me, but hey—this time it's AJAX.
There are multiple problems with this approach, however—such as the fact that on some server platforms, such a request will uselessly block a server process. Of course, then they invented “non-blocking IO”, which alleviates the problem. Java has this (but I can't describe how much I don't like Java).
Then, the HTTP standard enforces a limit on the concurrent requests from a client to a server: the client can open at most 2 simultaneous requests. This means that while your AJAX request waits for some answer, you can only do at most one other request to the server. As you can guess—there are ways to work around this too.
Then, there's also an overhead for every request—such as a DNS lookup, a client-server handshake, etc. This could never match the performance that an already open socket provides.
So what I don't understand is: why the heck don't we have plain old sockets? So simple, so powerful, so old and proven—and yet we invent buzzwords to work around this limitation!...