Works .. well, sometimes.
And yeah, the code is a mess.
scott_s03 at schillmania.com
http://www.schillmania.com
I was trying to come up with some way of getting multiple web clients to talk to each other without using plug-ins, etc.. ie. relying solely on client-side technology standard to 5.x+ browsers. This is what I've come up with so far. (I am working on this for fun, but with adding multiplayer functionality to my DHTML Scorched Earth project in mind.)
"Two-way" communication between multiple clients without page reloading (woo!)
An iFrame is used to receive messages; HTTP requests are used for sending.
If you use Mozilla, a PHP script acts as a proxy for "streaming" the RPC data, required in order to work around Mozilla cross-domain security stuff. A direct connection is established by the client when sending messages to the server.
If you're using IE, a direct connection is also used for the RPC data stream; Cross-frame script communication is allowed in IE as long as the frame is in the same domain - It doesn't seem to mind a different port, unlike Mozilla.
The PHP script connects to the broadcast server, a simple multithreaded app; the broadcast server listens on 2 ports, sending one-way data on each channel. The server is quite simple at this point, but features could easily be added.
An iFrame loads data from a socks broadcast server (modified HTTP/1.0, sorta.)
This iFrame is the communications channel for receiving events (messages) from other clients and the server. I call it the "RPC Frame", as it forms the link. The iFrame is pointed to the broadcast server, where events are sent from.
Javascript blocks are created "on-the-fly", and are sent by the server as it receives events from clients. The RPC frame is basically a regular old HTML page that never finishes loading because no "content-length" HTTP header is given, and the server closes the connection only if the client hangs up first.
(Normally if a content-length header is given, eg. 1024 bytes, the client will automatically close the connection after 1024 bytes have been received. By not providing a length, the client will keep the connection until the server drops or the client hangs up. At least, this is how I believe it works!)
Hence the "opening page" and "transferring data" messages you see in IE and Mozilla respectively, along with the animated "throbber" icons showing loading of data. There *is* data coming down the line, just very slowly ;)
Because of cross-browser security issues, the RPC page must reside on the same server (and even port according to Mozilla apparently!) as the web page; for this reason, a proxy is used with Mozilla - under IE it'll connect directly.
In either case, a "persistent" connection (ie. one that does not close) is opened between client and broadcast server. As the server receives events, they may be broadcasted to all connected clients depending on the event type.
To post a message, the client loads a URL through a Javascript element and passes the message data as a parameter in the URL. This connection is made on a different port, and is made directly as there are no cross-browser security issues here (the script sent down at this point does not make any calls to the parent frame, but the capability is there and will likely be used later on.)
Mozilla Firebird complains about some XULElement stuff when receiving messages.
Mozilla 1.3a is fine however.
Netscape sometimes doesn't clue in at first, but all is well after a refresh.
There seem to be some issues with the PHP-based proxy, a simpler CGI-based one may be a better idea. I suspect it has to do with a limitation on the number of instances of PHP allowed to run simultaneously on the web server, something to that effect - With multiple windows open on the same machine, the site seems to hang while loading. Without the PHP this is not an issue, however.
Who knows, could be literally tons of other bugs here.
- Scott | schillmania.com
|
|