Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
IMAP - debug a EIdSocketError # 10060 connection timeout error under a complex env.
#1
Exclamation 
My multi-threaded program uses TidIMAP4 to access Gmail's IMAP server with OAuth 2 authentication. 

My computer's network environment is a little complex - here we have the GFW blocking overseas services including Gmail, so the program connects through OpenVPN(through stunnel) and ShadowSocks proxy.


The setup works for other programs including Chrome, etc.

With the setup my program's thread 2 had several successful login, but most of the time, it fails to connect with the 'EIdSocketError: Socket Error # 10060 Connection timed out.' error.

With TIdLogEvent I can see that there is no data coming in and out. And this is thread 2, but thread 1 is ok - it can connect, login, select mailbox, and so on.

the logic works like this: thread 1 login and download folder/label list, email IDs, and so on, when done, it pushes the downloaded data to a queue and several instances of 'thread 2' will start to login. And the above described error happens in 'thread 2'.

I know the issue might come from the GFW, but the strange thing is why 'thread 1' can login but 'thread 2' fails? They login with the same function and same parameters.

I intend to diagnose with Wireshark, but don't know how to setup after trying many kinds of setup.

Any hints or suggestions? Thanks.

PS, the program most of the time works with direction Internet connection on a remote windows VPS which is located in the US, but still sometimes it gets the "EIdReplyIMAP4Error" exception
Reply
#2
(10-27-2018, 01:41 PM)edwinyzh Wrote: My multi-threaded program uses TidIMAP4 to access Gmail's IMAP server with OAuth 2 authentication. 

Indy does not support OAuth2, what are you using for that?

(10-27-2018, 01:41 PM)edwinyzh Wrote: With the setup my program's thread 2 had several successful login, but most of the time, it fails to connect with the 'EIdSocketError: Socket Error # 10060 Connection timed out.' error.

Are you using a non-infinite ConnectTimeout?

(10-27-2018, 01:41 PM)edwinyzh Wrote: With TIdLogEvent I can see that there is no data coming in and out.

The TIdLog... components don't really log the underlying connection activity, other than attempts to connect and disconnect, but not what those actions do internally. The components are more to log application-level data instead. So, if there is no connection, there is no application data being exchanged, so there is nothing meaningful to log.

(10-27-2018, 01:41 PM)edwinyzh Wrote: And this is thread 2, but thread 1 is ok - it can connect, login, select mailbox, and so on.

Well, then you don't really have a networking problem. Unless TIdIMAP4 in thread 2 is trying to use a different network than the one that TIdIMAP4 in thread 1 is using. Are you using the TIdIMAP4.BoundIP property at all to control which network TIdIMAP4 actually uses? If not, then it is up to the OS to decide, not Indy.

(10-27-2018, 01:41 PM)edwinyzh Wrote: I know the issue might come from the GFW, but the strange thing is why 'thread 1' can login but 'thread 2' fails? They login with the same function and same parameters.

Does thread 2 use its own local instance of TIdIMAP4? Or is it sharing TIdIMAP4 with thread 1?

(10-27-2018, 01:41 PM)edwinyzh Wrote: PS, the program most of the time works with direction Internet connection on a remote windows VPS which is located in the US, but still sometimes it gets the "EIdReplyIMAP4Error" exception

That has nothing to do with networking. EIdReplyIMAP4Error is raised whenever TIdIMAP4 receives an error message from the IMAP4 server itself. That is something you can use the TIdLog... components to diagnose, at least.

Reply
#3
Thanks for the help @rlebeau, please find my replies start with 'edwin:' below.

(10-29-2018, 07:42 PM)rlebeau Wrote:
(10-27-2018, 01:41 PM)edwinyzh Wrote: My multi-threaded program uses TidIMAP4 to access Gmail's IMAP server with OAuth 2 authentication. 

Indy does not support OAuth2, what are you using for that?

Edwin: Forgot to gave details, I use a modified version of https://github.com/lordcrc/IndySASLOAuth2 (internally uses tms cloud pack)

(10-27-2018, 01:41 PM)edwinyzh Wrote: With the setup my program's thread 2 had several successful login, but most of the time, it fails to connect with the 'EIdSocketError: Socket Error # 10060 Connection timed out.' error.

Are you using a non-infinite ConnectTimeout?
edwin: No, I use the default timeout values.


(10-27-2018, 01:41 PM)edwinyzh Wrote: And this is thread 2, but thread 1 is ok - it can connect, login, select mailbox, and so on.

Well, then you don't really have a networking problem.  Unless TIdIMAP4 in thread 2 is trying to use a different network than the one that TIdIMAP4 in thread 1 is using.  Are you using the TIdIMAP4.BoundIP property at all to control which network TIdIMAP4 actually uses?  If not, then it is up to the OS to decide, not Indy.

Edwin: No, I don't use BoundIP.

(10-27-2018, 01:41 PM)edwinyzh Wrote: I know the issue might come from the GFW, but the strange thing is why 'thread 1' can login but 'thread 2' fails? They login with the same function and same parameters.

Does thread 2 use its own local instance of TIdIMAP4?  Or is it sharing TIdIMAP4 with thread 1?
Edwin: Each thread has its own instance of TidImap4, but using the same property setup to connect and login.
Reply
#4
(10-30-2018, 08:21 AM)edwinyzh Wrote: Edwin: Each thread has its own instance of TidImap4, but using the same property setup to connect and login.

Then there is no reason why one would work and another one would not. Especially since you say thread 2 sometimes works, and sometimes not. So something else is going on. You are going to have to debug further to find out what exactly. There has to be some difference when a failure occurs.

Reply
#5
@rlebeau, thanks for the help! you are right! There is a bug in the code that set's the socks5 proxy for the connnection.

I didn't think there will be a bug, one of the reasons is that I've been seem too much strange errors due to the GFW here.

But during the fixing of the bug I gained a lot, thank you for the help rlebeau!
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)