One could hack around this by faking state, no? Have the client open a socket to the server and the server can just manually heartbeat it so that the connection is not dropped (the client of course must read off and discard the heartbeats). We're doing this (and more along the same lines) at Truviso and it works reasonably well (although there are some pretty hideous corner-case problems with--surprise--Internet Explorer).
Doing this with URLStream (the way we do) will count a connection against your total open limit (discussed in a number of places; e.g., here: http://www.openajax.org/runtime/wiki/The_Two_HTTP_Connection_Limit_Issue ). Note also that maintaining an open connection (and more importantly, a thread) per client is not very efficient, and may not be appropriate for all setups. Doing this with a raw Socket should also be possible (though you'd need an open port), would avoid the connection limit issue, and (I'm pretty sure) would be more scalable. Also, you may need to deal with temporary disconnections when the socket connection fails, but the client is still there. For us, we just disconnect the client entirely and try to reconnect with a fresh start, but that might be less than ideal. -- Maciek Sakrejda Truviso, Inc. http://www.truviso.com -----Original Message----- From: Seth Hodgson <shodg...@adobe.com> Reply-To: flexcoders@yahoogroups.com To: flexcoders@yahoogroups.com <flexcoders@yahoogroups.com> Subject: RE: [flexcoders] Re: Anything other than a JS alert can delay a window close? Date: Mon, 15 Dec 2008 11:40:24 -0800 HTTP session timeout at the server is the only sure-fire way to detect a client has left. Catching Javascript events at the client and attempting to notify the server may shortcut this process _when_ it works - but it provides no guarantees that it will. Even if your Javascript is able to put a request onto the network or get Flash to issue a request via ExternalInterface before the browser closes, the notification over the network could be lost, for instance if an intermediate router crashes. Depending on the behavior of your app, you can shorten this time interval by lowering your session timeout in web.xml. If you're trying to detect the client leaving specific pages this is more difficult with HTTP because your "connection" (i.e. session) spans all the pages of your site that are loaded in the browser process. When the session times out, you could treat this as a "leave" for all pages the client has viewed during its session. For RTMP (not available in BlazeDS) because we're dealing with a stateful connection (unlike HTTP where connections are stateless) as soon as the RTMP connection closes when the user closes their browser or navigates away from a page containing your Flex app, we detect that and you can respond to this event on the server. In this case, if different pages contain individual swfs that you're tracking, as soon as the client leaves a page and the connection closes you can track that directly. Best, Seth From: flexcoders@yahoogroups.com [mailto:flexcod...@yahoogroups.com] On Behalf Of valdhor Sent: Wednesday, December 10, 2008 5:58 AM To: flexcoders@yahoogroups.com Subject: [flexcoders] Re: Anything other than a JS alert can delay a window close? Another idea... How about setting up a timer in Flex to poll the server. If the server does not receive the poll in a certain amount of time then the client has disconnected and you can write the data to the database. It may work even better with BlazeDS (I don't know this - I'm kinda hoping it works). Hopefully you can tell if a client disconnects from something they have subscribed to via RTMP. Does anyone know?
