Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

idTcpServer or idCmdTcpServer - D7 indy10.1.5

102 views
Skip to first unread message

Jacques Noah

unread,
Apr 18, 2006, 11:47:39 AM4/18/06
to
I'm basically working on a program to manage internet access in a internet
cafe. What i want to do is to have a client/server system were the server
sends most of the commands and the clients just reply,i've about 20 clients.
Firstly, i would like to know what component is the best suited for this
task between idTcpServer and idCmdTcpServer?

Also, i've worked with the idTcpServer before, so i know how to send and
recieve commands with it, does idCmdTcpServer use the same methods to send
and recieve cmds? For example, if i have a cmd called 'status' how would i
send it to the client from the server using a button?

Cheers


Remy Lebeau (TeamB)

unread,
Apr 18, 2006, 2:19:51 PM4/18/06
to

"Jacques Noah" <jacque...@btinternet.com> wrote in message
news:4445...@newsgroups.borland.com...

> What i want to do is to have a client/server system were the
> server sends most of the commands and the clients just reply

Most or all? It makes a big difference.

> Firstly, i would like to know what component is the best suited
> for this task between idTcpServer and idCmdTcpServer?

You need to answer the above question first. Your answer to that question
will control which component to use.

> Also, i've worked with the idTcpServer before, so i know how to
> send and recieve commands with it, does idCmdTcpServer use the
> same methods to send and recieve cmds?

TIdTCPServer does not handle any commands automatically. It only has the
OnExecute event available, so you have to do all handling yourself.

TIdCmdTCPServer is a dedicated receive-commands/send-replies type of server.
It cannot send commands to clients, unless those commands are sent in
response to commands that it received. In other words, receive a command,
then immediately send a command, then receive the response, then send the
response to the original command. Or receive a command, then send the
response, then immediately send a command, and then recieve the response.

> For example, if i have a cmd called 'status' how would i send it to the
client from the server using a button?

Via the SendCmd() method, just like you would if the client were sending a
command to the server.


Gambit


Jacques Noah

unread,
Apr 18, 2006, 6:14:47 PM4/18/06
to
> Most or all? It makes a big difference.
Well the clients have to sent their status to the server, for example when a
user has reached the end of their allowed internet access time, the client
would send a message back to the server telling it that it is 'free'. That
is the only communication between the server and the client apart from the
onConnect event.

Cheers


"Remy Lebeau (TeamB)" <no....@no.spam.com> wrote in message
news:44452e6b$2...@newsgroups.borland.com...

Remy Lebeau (TeamB)

unread,
Apr 18, 2006, 6:49:43 PM4/18/06
to

"Jacques Noah" <jacque...@btinternet.com> wrote in message
news:4445...@newsgroups.borland.com...

> Well the clients have to sent their status to the server, for example


> when a user has reached the end of their allowed internet access
> time, the client would send a message back to the server telling it
> that it is 'free'.

Or, the client could simply disconnect without telling the server at all,
and the server can automatically "free" any dropped connections.

> That is the only communication between the server and the client
> apart from the onConnect event.

Based on your description above, if you do what I suggest, there you would
have no more need for the client to send commands to the server. Code-wide,
you can then use TIdTCPServer on the server-side, and TIdCmdTCPClient on the
client-side. As for status updates, you could have the server periodically
poll the active clients via a command that they respond to. That would also
act as a kind of keep-alive so the both the client and server can detect
lost connections.


Gambit


Jacques Noah

unread,
Apr 18, 2006, 8:49:34 PM4/18/06
to

> Or, the client could simply disconnect without telling the server at all,
> and the server can automatically "free" any dropped connections.

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. basically, i want everything to
be controlled from the server application.

Maybe i'm not doing this right, but when i try to send a cmd from the
server(using idTcpServer) i cant find the SendCmd() property or anything
else that i can use to send a cmd. there is the OnExecute property that
responds to cmds recieved from clients which is fine, but how do i send a
cmd using a button for example, i need to sent a cmd like the following:

start:10@WorkStation1

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:

TiContext = class(TIdContext)
public
IP: String;
Con: TDateTime;
compname:string;
procedure SendCd(const WStation: string; const mins:integer);
end;

The procedure checks if a client name exist on a list and then sends the
information to it. I just need to know how to send this info to the client
from a button event.

I hope this makes sense..
cheers


"Remy Lebeau (TeamB)" <no....@no.spam.com> wrote in message

news:44456dad$1...@newsgroups.borland.com...

Remy Lebeau (TeamB)

unread,
Apr 19, 2006, 1:06:33 AM4/19/06
to

"Jacques Noah" <jacque...@btinternet.com> wrote in message
news:4445...@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


0 new messages