Initial connection to D3 Windows

Boot D3 Windows and connect an AccuTerm session. Depending on network latency, for whatever reason, we may see a pause for a few seconds:


Strap yourselves in, we're going deep...

Can anyone, ( Pete? ) tell us what exactly triggers that dialog? I mean, I'm guessing that there is an initial timeout of maybe 500ms, where if there is no response, the dialog is displayed and another attempt is made to connect on the socket with a longer timeout.

Different but related ... When D3 is first booted, and we connect to a telnet session, D3 requires a CRLF to activate the process and return the first request for a D3 User: "Enter your user id:". Logout/disconnect. Now the workspace is "primed" and on the next connection the CRLF is not required. Immediately on socket connection/negotiation we get the login prompt. I understand this is a D3 thing. Surprisingly I don't think I've seen this in D3 v10.3, maybe they finally did something about that.

My immediate challenge is to get a connection to D3 Windows as fast as possible, try to avoid the show/hide of the "connecting" dialog, and get to the login prompt quickly regardless of whether the PIB has been activated previously.

To handle the second part of that, I usually just force a CRLF on connection, then wait for the user prompt before sending a login sequence. The extra EOL gets by the described nuance and does not affect the login.

What I'm looking for is a way to streamline this process, understand exactly what's happening at a low level, and maybe use events or timeouts to know exactly what state the connection is in so that I can get code to react more quickly. ... And this might change depending on the version of D3 Windows, and maybe with other MV platforms and OS's.

Has AccuTerm been tuned to accommodate these nuanced behaviors with D3, specific versions, or other platforms?

Thanks!