On Wed, 26 Mar 2008 12:54:11 -0700, "Remy Lebeau \(TeamB\)"
<no.spam@no.spam.com> wrote:
>
>"Bo Berglund" <bo.berglund@telia.com> wrote in message
>news:tt7lu35i601fjqmimenlicduie8fouovk8@4ax.com...
>
>> I don't see what you mean by disconnecting. The disconnect is
>> done by the client, not by the server, so what should the server
>> do about it?
>
>The server still has to close its endpoints of the connections as well.
>When a client disconnects normally, TServerSocket should be doing that
>automatically for you.
>
>> The server is non-blocking.
>
>Do you have an active message loop running in the thread that is using the
>TServerSocket? When a client is disconnected, whether by the client or the
>server, the TCustomWinSocket object is not freed right away. It posts a
>CM_DEFERFREE message to a hidden window that TServerSocket has. If you are
>not allowing new messages to be processed, that might account for why you
>are seeing the ActiveConnections value increase unexpectedly.
>
>> What I do on connect is this (trivial stuff removed):
>
>You are not using the code I gave you earlier. You need to Close() the
>TCustomWinSocket when you detect that a previous connection already exists.
>All you are doing is logging it but then not closing the new connection at
>all. Try this instead:
Yes, I am deliberately taking it stepwise and since I soon discovered
that the active connections incremented I did not put in the close()
call. I did not think it worthwhile to do the forced close yet. The
reason is that I would wind up with a server that could be connected
to *once* only!
As soon as the first client disconnected noone would be able to
connect at all since the active connections never decrement.
I have to fix that first, so the focus has really now shifted to
getting my server work decently. This would mean to return socket
resources on client disconnects etc.
So my code is now aimed at finding out what is going on when clients
disconnect.
I tried to put a socket close in a few of the places I thought of
where the disconnect is detected but it caused an eternal loop on the
server where the close itself triggered the event that ended by the
close being called ad infinum.
I tested it on an accessible server though, so I could use Task
Manager to shut it down.
/BoB
