BorlandTalk.com

Rich Como · Guest

My SMTP app calls disconnect which seems as if the disconnect property now
send a QUIT command. If this QUIT command which is sent to the peer fails,
the SMTP component still thinks it is connected and disconnect can be called
over and over and even though the connection is gone, The SMTP component
will never believe the connection is actually closed. SO subseqent calls to
connect results in an "already connected" Exception.

In previous versions I have used SMTP.DisconnectSocket which closes the
connection without issue. The Disconnectsocket procedure is no longer
available in the new indy 10.

Question bieng, is there a way to disconnect on the client side immediately
and letting the SMTP component know it is closed I have tried...

IOHandler.Close
SMTP.Disconnect( True )
IOHandler.CloseGracefully

all without success.

Also, Thanks for your help in the past Gambit with not one playing card
thrown at me.

Remy Lebeau (TeamB) · Guest

"Rich Como" <salgraz (AT) hotmail (DOT) com> wrote

Rich Como · Guest

Disconnect with a parameter is AImmediate, and ANotifyPeer is it just
Disconnect( False )

does disconnect( False ) mean false for AImmediate or ANotifyPeer?

"Remy Lebeau (TeamB)" <no.spam (AT) no (DOT) spam.com> wrote

Rich Como · Guest

Remy, here is sample code

for i := 1 to Round( ConnectionAttempts ) do //ConnectionAttempts = 4
begin
try
SMTP.Connect;
es := ''; //Error String
break; //If this hits, connection was successful, no more
attempts

except
on e:exception do
begin
try
es := es + ' [e:disconn start]'; //Denote in
error string that a disconnection is attempted
SMTP.Disconnect(False);
es := es + ' [e:disconn end]'; //If this appears
in error string we know the disconnect call was without errors
except
on e:exception do
begin
es := es + '[e: disconnect error:' + e.Message+']';
//if disconnect throws an exception we know what it is in the error string
end;
end;
es := es + IntToSTr(i) + ': FAIL ON CONNECT: ' + e.Message; // Link
all connection attempt error strings together
end;
end;

Generates this error string ( value of es )

FAILED [e:disconn start] [e:disconn end]1: FAIL ON CONNECT: Already
connected. [e:disconn start] [e:disconn end]2: FAIL ON CONNECT: Already
connected. [e:disconn start] [e:disconn end]3: FAIL ON CONNECT: Already
connected. [e:disconn start] [e:disconn end]4: FAIL ON CONNECT: Already
connected.

The error string shows that the call to disconnect(false) was successful but
for some reason, when it loops back, already connected still shows up

"Remy Lebeau (TeamB)" <no.spam (AT) no (DOT) spam.com> wrote

Rich Como · Guest

Clearly, Disconnect is not making the connected property false in some cases
displayed here where directly after the successful disconnect call connected
property remains true.

for i := 1 to Round( ConnectionAttempts ) do
begin

if IsPaused then Exit;

try
es := es + '[Calling Connect Attempt : ' + IntToStr( i ) + ' -
SMTP.Connected=' + BoolToSTr( SMTP.Connected, True ) +' ]';
SMTP.Connect;
es := '';
break;

except
on e:exception do
begin
try
es := es + ' [e:disconn start]';
SMTP.Disconnect(False);
es := es + ' [e:disconn end - SMTP connected: ' + BoolToSTr(
SMTP.Connected, True )+ ']';
except
on e:exception do
begin
es := es + '[e: disconnect error:' + e.Message+']';
end;
end;
es := es + IntToSTr(i) + ': FAIL ON CONNECT: ' + e.Message;
end;
end;

Result:

[Calling Connect Attempt : 1 - SMTP.Connected=True ] [e:disconn start]
[e:disconn end - SMTP connected: True]1: FAIL ON CONNECT: Already connected.
[Calling Connect Attempt : 2 - SMTP.Connected=True ] [e:disconn start]
[e:disconn end - SMTP connected: True]2: FAIL ON CONNECT: Already connected.
[Calling Connect Attempt : 3 - SMTP.Connected=True ] [e:disconn start]
[e:disconn end - SMTP connected: True]3: FAIL ON CONNECT: Already connected.
[Calling Connect Attempt : 4 - SMTP.Connected=True ] [e:disconn start]
[e:disconn end - SMTP connected: True]4: FAIL ON CONNECT: Already connected.

"Rich Como" <salgraz (AT) hotmail (DOT) com> wrote

Remy Lebeau (TeamB) · Guest

"Rich Como" <salgraz (AT) hotmail (DOT) com> wrote

Rich Como · Guest

Yes, But I cannot call connect again at all because it returns with "already
connected" over and over with no way of connecting ever again. Yet cannot
call disconnect(false) which does not throw exceptions, but returns
successfully

I have noticed when this issue happens IOHandler.Opened is False and
SMTP.Connected is true which shouldnt ever happen (Im assuming)

My IOHandler is a TIDIOHandlerstack.

This leads me to believe that the Disconnect procedure is checking if
iohandler is open, if its not, dont set the "connected" flag false (Possably
assuming that its already false) But there is a bug which IOHandler is
closing and not thetting the SMTP components connected property to false

Im assuming the IOHandler is never supposed to be closed with the
SMTP.connected: true. But this is happening. The following shows this
(Excerpt from IdTCPConnection)

procedure TIdTCPConnection.Disconnect(ANotifyPeer: Boolean);
begin
try
// Separately to avoid calling .Connected unless needed
if ANotifyPeer then begin
if Connected then begin
DisconnectNotifyPeer;
end;
end;
finally
{
there are a few possible situations here:
1) we are still connected, then everything works as before,
status disconnecting, then disconnect, status disconnected
2) we are not connected, and this is just some "rogue" call to
disconnect(), then nothing happens
3) we are not connected, because ClosedGracefully, then
LConnected will be false, but the implicit call to
CheckForDisconnect (inside Connected) will call the events
}
// We dont check connected here - we realy dont care about actual socket
state
// Here we just want to close the actual IOHandler. It is very possible
for a
// socket to be disconnected but the IOHandler still open. In this case
we only
// care of the IOHandler is still open.
//
// This is especially important if the socket has been disconnected with
error, at this
// point we just want to ignore it and checking .Connected would trigger
this. We
// just want to close. For some reason NS 7.1 (And only 7.1, not 7.0 or
Mozilla) cause
// CONNABORTED. So its extra important we just disconnect without
checking socket state.
if Assigned(IOHandler) then begin
if IOHandler.Opened then begin
DoStatus(hsDisconnecting);
IOHandler.Close;
DoOnDisconnected;
DoStatus(hsDisconnected);
end;
end;
end;
end;

Note the

if Assigned(IOHandler) then begin
if IOHandler.Opened then begin
DoStatus(hsDisconnecting);
IOHandler.Close;
DoOnDisconnected;
DoStatus(hsDisconnected);
end;

This shows that if IOHandler is closed, It will not call code to falsify the
connected flag for TIDSMTP.

Know any work around to set the connected property to false for IDSMTP if
the IOHandler becomes closed?

"Remy Lebeau (TeamB)" <no.spam (AT) no (DOT) spam.com> wrote

Remy Lebeau (TeamB) · Guest

"Rich Como" <salgraz (AT) hotmail (DOT) com> wrote

Chad Z. Hower aka Kudzu · Guest

There is a possible bug here when Disconnect is called and data still exists
in the buffer. For errorred disconnects it needs to preserve the data, but
should clear it on explicit disconnects.

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
"Programming is an art form that fights back"

Got Indy? Got the book?

http://www.atozed.com/indy/book/

Rich Como · Guest

Im assuming

IOHandler.WriteBufferFlush;
SMTP.Disconnect(False);

If so, an exception occurs when writebufferflush is called. Could you
please provide me with the correct convention or should I put the indy10
conversion untill the full release?

thanks
Rich

"Chad Z. Hower aka Kudzu" <cpub (AT) hower (DOT) org> wrote

Remy Lebeau (TeamB) · Guest

"Rich Como" <salgraz (AT) hotmail (DOT) com> wrote

Rich Como · Guest

Supurb.

IOHandler.InputBuffer.Clear;
SMTP.Disconnect(False);

worked

Thanks!

"Remy Lebeau (TeamB)" <no.spam (AT) no (DOT) spam.com> wrote

Chad Z. Hower aka Kudzu · Guest

"Rich Como" <salgraz (AT) hotmail (DOT) com> wrote in news:41ab737b$1
@newsgroups.borland.com: