[Twisted-web] Athena & browser 2-connection limit

glyph at divmod.com glyph at divmod.com
Tue Sep 16 06:56:44 EDT 2008


On 07:08 am, wthie at thiengineering.ch wrote:
>Hello Harald
>
>Try the following before you proceed:
>
>Run the nevow examples, go to calculator with IE7 or greater, then hit 
>F5 for reload in rapid sequence. You will hit the point where the 
>browser sits there seemingly deactivated with a waiting cursor. Wait 
>for the time it takes for the socket to come out of its TIME_WAIT state 
>and see the browser window come alive again.
>
>You can provoke this behavior also by providing a sequence of 
>LivePages, going from one LivePage to the other.
>
>The Athena implementation which was rewritten at SVN version 13786 to

This doesn't look like a rewrite of Athena:

    http://divmod.org/trac/changeset/13786

I think you meant SVN version 14017?

    http://divmod.org/trac/changeset/14017

Or maybe something else?
>implement a better disconnect logic collides in my experience with the 
>limited connections IE's developer decided to use. At any particular 
>time the browser accepts only two open sockets (...)

>This is in my opinion a fundamental flaw in the current Athena 
>implementation and leads to problems no end, because users WILL simply 
>NOT behave and will do the impossible. User feedback in our case was 
>so, that I was forced to live with the 'old' Athena stuff.

I don't think the flaw is in any way "fundamental".  The whole design of 
Athena is based around the idea that all the pieces are pluggable and 
can be substituted.  For example, ReliableMessageDelivery is a separate 
class specifically so that it can be modified in isolation and we can 
change this strategy without touching the rest of athena.
>If you or anybody else sees a solution to that IE/TIME_WAIT problem I 
>would be more than happy to invest time into furthering Athenas 
>evolution, I like the concepts underneath and if they're coupled with a 
>decent JScript library the 'real app in the browser' becomes a reality.

Several things come to mind.

One is that you could simply submit a patch to ReliableMessageDelivery 
to make it better.  There are a number of obvious flaws with the current 
implementation and it would be nice if it could be fixed.  This is not a 
very specific idea because browsers are awful, and I don't know of any 
collection of pure-Javascript gross kludges to work around their 
awfulness better than the current collection of gross kludges.

Another is that we could abuse a browser extension that supports real 
sockets - say, Flash - to provide a better "default" experience, but 
fall back to the current crummy behavior for the few users that don't 
have it.  A long time ago we did this, and there was a flash movie 
called 'flashconduit' included with Nevow's predecessor (Woven).  At the 
time this was impossible to build and test either in an automated way or 
on an open-source platform, so we abandoned that strategy.

Recently I've been playing with Flex, which is (among other things) a 
toolkit for building Flash movies out of actual source code rather than 
the atrocity that is a .FLA file.  It's also amenable to automated 
builds and testing, which FLA files had impeded in the past.

Java is another option, and although the typically long startup time for 
applets wouldn't make it ideal, it might be a reasonable backup option. 
I hear .NET has something called "no touch deployment", and Firefox has 
a socket API for extensions which an extension could selectively expose 
to the web page context.

Anyway, all of these options are really just different ways that the RDM 
might be adjusted; all of them could be implemented and the best option 
selected automatically based on the user's browser.  Given that you seem 
to have some specific requirements based on specific user experiences, I 
hope that you'll contribute patches that we can discuss and test in a 
variety of different browser situations.



More information about the Twisted-web mailing list