The Player uses the browser's network layer so it's all about whether the browser will return control, and I believe it's up to the browser to decide whether it's a keep-alive or not. I'll see if I can find anything else out though. Matt
________________________________ From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On Behalf Of erikabair Sent: Wednesday, May 02, 2007 1:03 PM To: flexcoders@yahoogroups.com Subject: [flexcoders] Connection pools in the FlashPlayer and forcing a close of an URLLoader/Stream Hello, I'm running into an issue with URLLoader::close (and URLStream::close) not actually doing a low-level close of the underlying TCP connection. Basically we have a situation in which we're doing a blocked poll against a server, and need to interrupt that blocked request in order to submit a new (higher prio) request. I've tried doing a close() call on the connection, tried doing a close and then ensuring that the URLLoader object is not reused, but it seems that the Player never actually attempts to close the underlying socket. I'm guessing that the failure to close is due to the fact that the flash player seems to be utilizing a connection pool behind the scenes: It seems that if I do a loadPolicyFile call, followed by a load via an URLLoader against the same host, Flash will open 2 keep-alive connections, and will then use one or the other underlying connection for all subsequent requests. This appears to cause an issue in certain browsers that limit the total number of persistent socket connections (if you check about:config in firefox you can see that network." http.max-persistent-connections-per-server" is set to 2 by default, both of which get used up by the flash player instance). So my questions are: 1) Is there a way to force the Player to actually close an underlying connection? 2) Is there a way to prevent the URLLoader from using a keep-alive based connection? Thanks, - Erik
