Article View: borland.public.cppbuilder.internet.socket
Article #1519Re: TidTCPServer and disconnections problems
From: Remy Lebeau (TeamB)
Date: Fri, 12 Jan 2007 21:55
Date: Fri, 12 Jan 2007 21:55
82 lines
3850 bytes
3850 bytes
"Stefano Bonifazi" <stefboombastic@email.it> wrote in message
news:45a7f92c@newsgroups.borland.com...
> Anyway if for some reason the user close the client application
> before it can send the disconnect command, the server
> application crashes
It will not crash. It will likely raise a suitable exception, which
is normal behavior by design. But that is NOT a crash.
> even if I wrapped the code inside OnExecute inside a try catch!
You shouldn't be doing that in the first place. TIdPeerThread has
exception handlers internally to deal with that appropriately. If you
must use exception handlers, then at least make sure not to disgard
any of Indy's own exception types (those derived from EIdException).
Re-throw them when needed.
> The same happens if I try to close the server application before
> all clients have disconnected!
Again, throwing an exception for an abnormaly closed connection is
perfectly normal behavior for Indy. It is by design. Ignore it. The
server will handle it internaly.
> this is my code inside OnExecute:
Get rid of the exception handler altogether. You are also not freeing
the Buffer. You don't need it anyway. Just use ReadString() instead
of ReadBuffer(). Try this code instead:
void __fastcall TForm1::IdTCPServer1Execute(TIdPeerThread
*AThread)
{
TNodzClientData* pNodz = (TNodzClientData*) AThread->Data;
AThread->Connection->ReadLn("�");
int command = AThread->Connection->ReadInteger(false);
int datasize = AThread->Connection->ReadInteger(false);
AnsiString Data = AThread->Connection->ReadString(datasize);
switch( command )
{
case cmdStringCommand:
if( Data=="Disconnect" )
AThread->Connection->Disconnect();
break;
...
}
AThread->Connection->ReadLn("�");
}
> Inside the OnDisconnect I call thread safe code for deleting my
custom data
Why are you maintaining a list of active clients in the first place?
TIdTCPServer already does that for you. You can access its Threads
property whenever needed. You can then allocate your TNodzClientData
inside the OnConnect event and free it in the OnDisconnect event
without any synchronizing at all. Even better, derive TNodzClientData
from TIdPeerThread and set the server's ThreadClass property, and then
you don't have to allocate/free anything at all.
> How should I correct my code in order it can handle Client
application
> closes
Get rid of the exception handler completely. You are hindering the
server's ability to handle abnormal disconnects. You are not helping
it.
> without crashes??
What you think is a crash is NOT a real crash. An exception in
general is NOT a crash. A real crash would be an unexpected exception
that is not handled, taking the whole server down with it. That is
not the case here.
Gambit
Technical Details
Message-ID:
<45a803d7$1@newsgroups.borland.com>Path:
arc1-ca.pugleaf.net!g2news2.google.com!news4.google.com!news.glorb.com!news2.volia.net!newsfeed01.sul.t-online.de!t-online.de!newsgroups.borland.com!not-for-mailReferences:
<45a7f92c@newsgroups.borland.com>Show Full Headers
Complete Article Headers
X-Google-Thread: 11508e,827d16ab792ef887 X-Google-Attributes: gid11508e,public X-Google-Language: ENGLISH,ASCII From: "Remy Lebeau \(TeamB\)" <no.spam@no.spam.com> Newsgroups: borland.public.cppbuilder.internet.socket References: <45a7f92c@newsgroups.borland.com> Subject: Re: TidTCPServer and disconnections problems Date: Fri, 12 Jan 2007 13:55:44 -0800 Lines: 84 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 NNTP-Posting-Host: 75.83.34.171 Message-ID: <45a803d7$1@newsgroups.borland.com> X-Trace: newsgroups.borland.com 1168638935 75.83.34.171 (12 Jan 2007 13:55:35 -0800) Path: arc1-ca.pugleaf.net!g2news2.google.com!news4.google.com!news.glorb.com!news2.volia.net!newsfeed01.sul.t-online.de!t-online.de!newsgroups.borland.com!not-for-mail