Hang issue with

#466

Author: BrianV
Date: Sat, 23 Feb 2008 03:51

97 lines
4371 bytes

I'm having lots of trouble getting Indy SMTP to work reliably for me.  I am 
using 10.1.5, the version that ships with C++ Builder 2007.  One of the 
issues I'm having is the following:

When calling Connect() on a IdSMTP component, the flow goes through Indy 
code like this:

/*------------------------------------------------------------*/
//   First, IdSMTP line 416
/*------------------------------------------------------------*/
procedure TIdSMTP.Connect;
begin
  inherited Connect; try
    GetResponse(220);
    SendGreeting;
  except
    Disconnect;
    Raise;
  end;
end;

/*------------------------------------------------------------*/
// Then here...
/*------------------------------------------------------------*/
function TIdTCPConnection.GetResponse(AAllowedResponse: SmallInt): SmallInt;
begin
  Result := GetResponse([AAllowedResponse]);
end;

/*------------------------------------------------------------*/
Then to IdTCPConnection line 547
/*------------------------------------------------------------*/
function TIdTCPConnection.GetResponse(
 const AAllowedResponses: array of SmallInt): SmallInt;
begin
  GetInternalResponse;
  Result := CheckResponse(LastCmdResult.NumericCode, AAllowedResponses);
end;

/*------------------------------------------------------------*/
Then to IdTCPConnection line 674
/*------------------------------------------------------------*/
procedure TIdTCPConnection.GetInternalResponse;
var
  LLine: string;
  LResponse: TIdStringList;
begin
  CheckConnected;
  LResponse := TIdStringList.Create; try
    // Some servers with bugs send blank lines before reply. Dont remember 
which
    // ones, but I do remember we changed this for a reason
    LLine := IOHandler.ReadLnWait;
    LResponse.Add(LLine);
    while not FLastCmdResult.IsEndMarker(LLine) do begin
      LLine := IOHandler.ReadLn;
      LResponse.Add(LLine);
    end;
    //Note that FormattedReply uses an assign in it's property set method.
    FLastCmdResult.FormattedReply := LResponse;
  finally Sys.FreeAndNil(LResponse); end;
end;

/*------------------------------------------------------------*/
and finally to IdIOHandler line 1199
/*------------------------------------------------------------*/
function TIdIOHandler.ReadLnWait(AFailCount: Integer = MaxInt): string;
var
  LAttempts: Integer;
begin
// MtW: this is mostly used when empty lines could be send.
  Result := '';
  LAttempts := 0;
  while (Length(Result) = 0) and (LAttempts < AFailCount) do begin
    Inc(LAttempts);
    Result := Sys.Trim(ReadLn);
  end;
end;

The neat thing about this last method, is that no matter what you set 
timeouts to, this last method is called without a value for AFailCount, and 
so it loops through MaxInt times.  So if a user ever enters an incorrect 
port for their SMTP connection, there doesn't seem to be any straightforward 
way to avoid an interminable timeout where the app just hangs.

I know this would be an easy fix in Indy, but the problem is that I've only 
spent a little time trying to make Indy work for me, and have hit a few 
pretty major issues like this that seem to be complete show stoppers for 
trying to use this in a commercial app.

Are there other SMTP components out there that are less buggy (but still 
work with SSL), or do I need to give Indy more of a chance?  A lot of the 
stuff Indy does is very impressive, but I have to say, so far it has been 
EXTREMELY frustrating.

Thanks for any advice,
Brian

Re: Hang issue with

#467

Author: Eugene Mayevski
Date: Sat, 23 Feb 2008 08:54

15 lines
1632 bytes

Hello!
You wrote  on Fri, 22 Feb 2008 20:51:32 -0700:

 B> Are there other SMTP components out there that are less buggy (but still
 B> work with SSL), or do I need to give Indy more of a chance?  A lot of

Check ElSMTPClient in SSLBlackbox package 
(http://www.eldos.com/sbbdev/delphi-ssl.php)
You get a straightforward and working SMTP with built-in TLS support, 
built-in MIME and S/MIME security and guaranteed technical support.

With best regards,
Eugene Mayevski
http://www.SecureBlackbox.com - the comprehensive component suite for 
network security

Re: Hang issue with

#468

Author: Asger Joergensen
Date: Sat, 23 Feb 2008 11:50

16 lines
1482 bytes

Hi BrianV 
 
 BrianV says:
> I'm having lots of trouble getting Indy SMTP to work reliably for me.  I am 
> using 10.1.5, the version that ships with C++ Builder 2007.  One of the 
> issues I'm having is the following:

I have seen Remy write about the Indy version that ships with
C++ Builder 2007, that it is not so good, so You probably need 
to upgrade it, but before You do so please searc the groups 
for the procedure, it is something about uninstalling the whole
Indy before You install a new version.

Kind regards
Asger

Re: Hang issue with

#471

Author: Remy Lebeau (TeamB)
Date: Mon, 25 Feb 2008 18:04

40 lines
2659 bytes

"BrianV" <bvanmatre_remove_@yahoo.com> wrote in message 
news:47bf9844$1@newsgroups.borland.com...

> I'm having lots of trouble getting Indy SMTP to work reliably for me.

Then you are likely using it wrong to begin with.  TIdSMTP is quite reliable 
when used properly.

> I am using 10.1.5, the version that ships with C++ Builder 2007.

As I told you in the other discussion thread you started, you are using an 
old version of Indy.  The current version is 10.2.3.

> When calling Connect() on a IdSMTP component, the flow
> goes through Indy code like this:
<snip>

The SMTP protocol dictates that the server is required to send a greeting to 
the client upon a successful connection to the server.  That is what 
GetResponse() is reading inside of Connect().

> The neat thing about this last method, is that no matter what
> you set timeouts to, this last method is called without a value
> for AFailCount, and so it loops through MaxInt times.  So if a
> user ever enters an incorrect port for their SMTP connection,
> there doesn't seem to be any straightforward way to avoid an
> interminable timeout where the app just hangs.

If the client connects to the wrong port, there is no way for Indy to detect 
that without reading from the socket.  In this situation, Indy is expecting 
the server to send a line of text.  If the server does not actually do that, 
the only thing Indy can do is wait for a timeout to elapse.  It is your 
responsibility to make sure you connect to the correct port to begin with. 
If you want a timeout to occur, then you will have to set the ReadTimeout 
property before calling Connect().  Otherwise, ReadLn() will use an infinite 
timeout by default and wait forever.


Gambit

Re: Hang issue with

#473

Author: BrianV
Date: Tue, 26 Feb 2008 05:01

51 lines
3199 bytes

Remy,
Thanks very much for your time.  I'll check out the latest indy code.


> As I told you in the other discussion thread you started, you are using an 
> old version of Indy.  The current version is 10.2.3.

I'll look at the latest and see what's different.


> If the client connects to the wrong port, there is no way for Indy to 
> detect that without reading from the socket.  In this situation, Indy is 
> expecting the server to send a line of text.  If the server does not 
> actually do that, the only thing Indy can do is wait for a timeout to 
> elapse.  It is your responsibility to make sure you connect to the correct 
> port to begin with. If you want a timeout to occur, then you will have to 
> set the ReadTimeout property before calling Connect().  Otherwise, 
> ReadLn() will use an infinite timeout by default and wait forever.


I am setting ReadTimeout, to 10 seconds (10000 ms).  To give a little deeper 
stack trace:

:006B47BC CheckIsReadable(AMSec=10000)
:006B4868 Idsockethandle::TIdSocketHandle::Readable(Self=:011D34C0, 
AMSec=10000)
:006B7625 Idiohandlerstack::TIdIOHandlerStack::Readable(Self=:01419E00, 
AMSec=10000)
:006CD5D3 
Idsslopenssl::TIdSSLIOHandlerSocketOpenSSL::ReadFromSource(Self=:01419E00, 
ARaiseExceptionIfDisconnected=true, ATimeout=10000, 
ARaiseExceptionOnTimeout=false)
:006B9267 Idiohandler::TIdIOHandler::ReadLn(Self=:01419E00, ATerminator={ 
"\n" }, ATimeout=-1, AMaxLineLength=16384)
:006B90C2 Idiohandler::TIdIOHandler::ReadLn(Self=:01419E00)
:006B9470 Idiohandler::TIdIOHandler::ReadLnWait(Self=:01419E00, 
AFailCount=2147483647)
:006AFC87 
Idtcpconnection::TIdTCPConnection::GetInternalResponse(Self=:01419F60)
:006AF834 Idtcpconnection::TIdTCPConnection::GetResponse(Self=:01419F60, 
AAllowedResponses=:0012D2B4, Result=18)
:006AFD3F Idtcpconnection::TIdTCPConnection::GetResponse(Self=:01419F60, 
AAllowedResponse=220)
:006D0790 Idsmtp::TIdSMTP::Connect(Self=:01419F60)

In other words, if I set the read timeout to 10 seconds, it waits 10 seconds 
2 billion times!  I've traced it in the debugger and this is what happens. 
I'll take a look at the latest version to see if it has the same behavior.

It does sound like it's worth the time to do the upgrade, and thanks again 
for your input.

Re: Hang issue with

#472

Author: BrianV
Date: Tue, 26 Feb 2008 05:08

9 lines
1424 bytes

> Check ElSMTPClient in SSLBlackbox package
> (http://www.eldos.com/sbbdev/delphi-ssl.php)
> You get a straightforward and working SMTP with built-in TLS support, 
> built-in MIME and S/MIME security and guaranteed technical support.

Thanks.  I downloaded the trial and it works great after about 20 minutes 
mucking around with it.  Still trying to make up my mind how much my time is 
worth!  Sometimes more than others...

Re: Hang issue with

#474

Author: Remy Lebeau (TeamB)
Date: Tue, 26 Feb 2008 17:29

12 lines
1417 bytes

"BrianV" <bvanmatre_remove_@yahoo.com> wrote in message 
news:47c39d1b$1@newsgroups.borland.com...

> In other words, if I set the read timeout to 10 seconds,
> it waits 10 seconds 2 billion times!

You need to upgrade.  ReadLnWait() does not do that anymore.  It will raise 
an EIdReadTimeout if ReadLn() timed out.


Gambit

🚀 go-pugleaf

Thread View: borland.public.cppbuilder.internet.socket

Hang issue with

Re: Hang issue with

Re: Hang issue with

Re: Hang issue with

Re: Hang issue with

Re: Hang issue with

Re: Hang issue with

Thread Navigation