Newsgroups : Borland : borland.public.delphi.internet.winsock : 2006 Apr : Re: idTcpServer or idCmdTcpServer - D7 indy10.1.5

www.cryer.info
Managed Newsgroup Archive

Re: idTcpServer or idCmdTcpServer - D7 indy10.1.5

Subject:Re: idTcpServer or idCmdTcpServer - D7 indy10.1.5
Posted by:"Remy Lebeau (TeamB)" (no.spam@no.spam.com)
Date:Tue, 18 Apr 2006 22:06:33

"Jacques Noah" <jacques.noah@btinternet.com> wrote in message
news:44458911@newsgroups.borland.com...

> The idea is that the server will act as the 'control center' for the
system.
> For example, when a new user wants to use the internet, the operator
> of the system should be able to 'unlock' a client computer by  sending
> a command to the client machine, whos name will be on a list that was
> created when a client connected to the server. The only time that the
> client should disconnect is when the internet cafe closes.

You are relying only on receiving graceful disconnects, but you are not
taking in account that abnormal disconnects can occur as well.

> basically, i want everything to be controlled from the server application.

Ok, so what is the problem exactly?  The design you have described does not
have the clients sending commands to the server at all.  The server knows
the status of all of the clients at all times, because it is the one issuing
the statuses in the first place.  So why do you need the clients to send
anything unsolicted to the server at all?  When the user wants to use a
computer, the server tells the client to unlock itself and it acknowledges
with a reply.  When the user is done using the computer, the server tells
the client to re-lock itself, and the client acknowledges with a reply.

> I use a parse function to break this up into: cmd, minutes to allow
> internet access and computername. This activates a timer on the
> client computer and allows the user 10 minutes internet access.
> I've created the class below to store client data:

On the server side, you have to retreive the TIdContext pointer for the
particular client that you are interested in.  You can then access its
Connection property as needed.  You can retreive such a pointer from the
server's Contexts property.  For example:

    procedure TForm1.Button1Click(Sender: TObject);
    var
        List: TList;
    begin
        List := IdTCPServer1.Contexts.LockList;
        try
            TiContext(List[SomeIndex]).SendCd("WorkStation1", 10);
        finally
            IdTCPServer1.Contexts.UnlockList;
        end;
    end;


Gambit

Replies:

none

In response to:

www.cryer.info
Managed Newsgroup Archive