Currently the scanner waits serverSelectionTimeoutMS to connect to all servers and receive ismaster responses. This doesn't match the spec:

The socket used to check a server MUST use the same connectTimeoutMS as regular sockets. Multi-threaded clients SHOULD set monitoring sockets' socketTimeoutMS to the connectTimeoutMS.

When a client waits for a server to respond to a connection, the client does not know if the server will respond eventually or if it is down. Users can help the client guess correctly by supplying a reasonable connectTimeoutMS for their network: on some networks a server is probably down if it hasn't responded in 10 ms, on others a server might still be up even if it hasn't responded in 10 seconds.

The socketTimeoutMS, on the other hand, must account for both network latency and the operation's duration on the server. Applications should typically set a very long or infinite socketTimeoutMS so they can wait for long-running MongoDB operations.

Multi-threaded clients use distinct sockets for monitoring and for application operations. A socket used for monitoring does two things: it connects and calls ismaster. Both operations are fast on the server, so only network latency matters. Thus both operations SHOULD use connectTimeoutMS, since that is the value users supply to help the client guess if a server is down, based on users' knowledge of expected latencies on their networks.

serverSelectionTimeoutMS on the other hand expresses the user's expectation of how long an election or other topology change might take. The two knobs should be kept distinct.

The selection time for a single-threaded client with serverSelectionTryOnce "on" (the default) should be affected by connectTimeoutMS, not serverSelectionTimeoutMS, but currently it's the opposite.