Newsgroups : Borland : borland.public.delphi.internet.winsock : 2008 Mar : Re: How to limit number of concurrent clients in TServerSocket?

www.cryer.info
Managed Newsgroup Archive

Re: How to limit number of concurrent clients in TServerSocket?

Subject:Re: How to limit number of concurrent clients in TServerSocket?
Posted by:"Remy Lebeau (TeamB)" (no.spam@no.spam.com)
Date:Thu, 27 Mar 2008 03:13:40

"Bo Berglund" <bo.berglund@system3r.se> wrote in message
news:9dmmu31ncs41646r53e1556q7cu0269j3e@4ax.com...

> I understand this completely...
> But I did not understand how I can get any communication to
> multiple clients isolated to them unless I did some tricks like
> passing the socket to a handler created on connection and then
> using this for communications.

Then you do not understand how to use TServerSocket correctly in general.
You should be using the OnClientRead and OnClientWrite events instead.


> OK, so I have to assign the communications object to a "Data"
> property of the socket on connect (after the object has been created).

That is not a requirement.  I did that only so the TClientComm object is
easily accessible to the other TSerrverSocket event handlers.  Since you
want only 1 TClientComm object to be active at a time, you could store the
pointer somewhere else of your choosing, if you are more comfortable doing
that.

> In fact maybe this is where I should destroy the object as well?

Yes.

> If I assign the Socket.OnSocketEvent in order to *internally* in
> the Comm object handle the incoming data

Again, DO NOT assign the OnSocketEvent at all!!!!  That is the wrong way to
handle this situation.  You need to use the TServerSocket.OnClientRead event
instead.  That is the only time you can safely read from a non-blocking
socket.

> Should I implement the OnClientRead event to retrieve the incoming
> data in this fashion maybe:

Yes.

> I assume that I can use the passed socket *inside* the Comm
> object to send data to the client?

Yes.  Or, simply pass the event handler's Socket parameter to the
TClientComm handlers each time, and not store it as a member at all.

> Something like this:

That is part of it.  Because you are using non-blocking sockets, you must
take into account when a writing operation fails due to blocking.  When that
happens, you must wait for the OnClientWrite event to fire before you can
write outbound data to the Socket again, starting with the data that
originally failed.  This usually means that you will have to cache the
failed data (and all subsequent data) in memory, and then send the cache
when OnClientWrite is fired.


Gambit

Replies:

In response to:

www.cryer.info
Managed Newsgroup Archive