538196 - [autoconfig] parallel scanning by autoconfig for faster port results

Status: VERIFIED DUPLICATE of bug 549040

(Thunderbird :: Account Manager, enhancement)

Description

[Alain Knaff]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9.1.6) Gecko/20091216 Fedora/3.5.6-1.fc11 Firefox/3.5.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.5) Gecko/20091209 Fedora/3.0-3.fc11 Lightning/1.0b1 Thunderbird/3.0

I noticed that the "new account" wizard is now able to automatically scan for open mail and imap ports on the server, greatly easing setup.

However, this scanning is performed sequentially (first port 143, then 993, ...) rather than in parallel. This wastes time if the server is firewalled to simply drop packets sent to an unused port rather than returning a connection refused.

If thunderbird would send out the connection requests to the various possible ports in paralell, this would greatly improve response time.

Reproducible: Always

Steps to Reproduce:
1. Set up a an imap server so that it listens on port 993 (imap/ssl)
2. Set up a firewall on the imap server so that it drops traffic to port 143.
3. In thunderbird, set up an account in that imap server's domain
Actual Results:  
The wizard tries to connect to port 143, and only moves on to port 993 after a lengthy timeout.

Expected Results:  
It should try all ports (143, 993, 110, 995) in paralell.

This can be achieved for instance by putting the socket into non-blocking mode before connect, and monitor for progress using select and getsockopt(SO_ERROR)

Interestingly enough scanning for incoming and outgoing server is already done in parallel to each other. However, the many ways how an incoming server may be reached are not scanned in parallel.

Comment 1

[Wayne Mery (:wsmwk)]

aceman, what do you think? 
Seems like this would add a fair bit if complexity.

Comment 2

[:aceman]

I don't know how complex this would be to implement.
Also creating a new account with detecting the server is a rare occurrence.
However, it needs some analysis to see how long that worst case scenario (firewalled server) can take and if TB UI is blocked in that case. If the UI freezes for 10 minutes while it autodetects the server, without the user able to stop it, than that is a bad experience and may cause the first-time user to abandon TB.

Comment 3

[Wayne Mery (:wsmwk)]

Alain, do you have an example server with extremely slow results?

Comment 5

[Ben Bucksch (:BenB)]

This is not a duplicate. This bug here is talking about guess config contacting mail servers. Bug 1500316 parallelizes the other HTTP fetch calls.

But this bug here has been fixed a long time ago already in bug 549040, so this is a dup of that one.

Comment 6

[Wayne Mery (:wsmwk)]

Indeed. thanks for fixing it up