I have two Delphi apps that need to communicate over the local network,
using IdTCPServer on server and IdTCPClient on the client application.
The IdTCPServer component is active all the time since I need an option for
the Clients to connect and send commands to Server when they need to. The
process goes as suggested:
Client.Connect->Client.SendSomeData->Client.Disconnect.

Now the "problem" ... occasionally the Server also needs to notify the
Client (one of them) about some situation (but as explained the Client is
NOT connected all the time).

The question: is it BETTER to leave the Client connected while client app is
working, OR to place an IdTCPServer component on each client application and
one IdTCPClient on the server? Or something totally different?

Suppose 25-30 client apps per "one server".

--
.............................................
Zarko Gajic, BSCS
About Guide to Delphi Programming
http://delphi.about.com
email: delphi.gu...@about.com
free newsletter: http://delphi.about.com/library/blnewsletter.htm
forum: http://forums.about.com/ab-delphi/start/
advertising: http://delphi.about.com/library/bladvertise.htm
.............................................

"Zarko Gajic <http://delphi.about.com>" <delphi.guide.nos...@about.com>
wrote in message news:3e2e55db@newsgroups.borland.com...

There are 3 possibilities:

1)Keep the connection open.
2)Use an IdTCPServer on each client
3)Use an IdSimpleServer on each client (=IdTCPServer without threads, and
which allows 1 connection)

ad 1) you'll need to put the IdTCPClient in a separate thread,
because if blocks all the time waiting for data
ad 2) would be the easiest way, because it manages the threads for you
ad 3) also needs a thread.

it depends a little about the frequency of the data to the client, but i
would say that using an IdTCPServer or an IdSimpleServer would be the best
(although keeping the connection open isn't wrong either)

Bas

About frequency. From Server to Client: very occasionally. And if I do leave
the connection open on the Client side, than I'll need  something like a
Timer to "wait" for Server commands?

It than seems that placing a IdTCPServer on each client would be the best
solution. I was just curious about system/network resources when having 25
Client/Server machines and one Server/Client machine?

.............................................
Zarko Gajic, BSCS
http://delphi.about.com
.............................................

"Zarko Gajic <http://delphi.about.com>" <delphi.guide.nos...@about.com> wrote in message
news:3e2e6503$2@newsgroups.borland.com...
Don't forget about firewalls...

--
Regards
Illya Kysil, software developer
Delphi/C/C++/C#/Java/Forth/Assembler
If it is NOT SOURCE, it is NOT SOFTWARE. (C) NASA

"Zarko Gajic <http://delphi.about.com>" <delphi.guide.nos...@about.com>
wrote in message news:3e2e6503$2@newsgroups.borland.com...

As long as no connections are made, no network resources are used.

Bas

Zarko Gajic <http://delphi.about.com> <delphi.guide.nos...@about.com>
wrote in message news:3e2e6503$2@newsgroups.borland.com...

It's not unusual to keep TCP connections open for ever.  While a
connection is open, but no data is being transferred, no CPU or
network loading is incurred.  Continually opening & closing
connections is wasteful of network & CPU & is only really useful
where huge numbers of clients are intermittently interacting, eg. a
web server.

If you keep the connection open, you really need a seperate thread on
the client to 'wait for server commands'.

Rgds,
Martin

Zarko Gajic <http://delphi.about.com> <delphi.guide.nos...@about.com>
wrote in message news:3e2ea41a$1@newsgroups.borland.com...

Well, I wouldn't do this at all.  With only 25-30 clients, I see no
problem in just letting the clients connect to the server & keep the
connection open.  This seems far simpler than running server
instances on each client, (to say nothing of resources used).  To
talk to the client, the server would have to either create a client
instance as required or keep a queue of client instances, ready for
connection.  This all starts to become very messy - far more complex
than one client-server connection and a read thread at each client.
There are some network scenarios where a complex solution is really
neccessary, but this doesn't seem to be one of them.

Instantiating a client component takes a significant amount of time -
so much that it is noticeable by humans.  Opening a connection,
similarly, takes a huge amount of time, (in computer terms).  Either
of these operations will sieze the calling thread for this time & the
latency in your communication will be very noticeable.  This may, or
may not, be important to your app.

Another problem is that of connection management.  The more
connections you have, the more difficult it is to control things.
It's bad enough keeping track of just one connection - see all the
posts regds 'onDisconnect not fired', 'How do I know if my client is
still there?', 'How do tell if the server has crashed?'.

If you have one connection, and keep it open, there is next to no
latency in communication.  No socket components need to be
instantiated during normal communication bursts.  There is no
connect-protocols continually being run.  There is only one
server<>client connection to control & manage.

The downside is that you need a read-thread at the client & your
protocol needs to allow for the 'two-way' communication.  I have
found this a small price to pay for reducing connection complexity.

Rgds,
Martin

news:3e2ec1e1@newsgroups.borland.com...

I agree, keeping the connection open is a better solution in my opinion.

Dan

Hello Folks,

I just finished an Instant Messaging Service that's working in more than
1000 computers of my customers without problems. I think it's it's very
similar to this question (clients permanently connected & server side
commands). You don't need nothing special for this application. You only
need to use TidTcpClient on the client machines and a TidTCPServer on the
server side. Connections are always active, but every x minutes you need to
send any command you want (ACK) to know if the connection was closed without
notification.

Thanks,

Francisco Ruiz
Autoware S.L.
Spain

"Dan F" <Da...@removeme.Bigfoot.Com> wrote in news:3e2ecb98$1
@newsgroups.borland.com:

If my opinion on Indy is of any use, I agree. ;)

--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

  Is Indy useful to you? Send a postcard please!
  http://www.hower.org/kudzu/indypost.html

ELKNews - Get your free copy at http://www.atozedsoftware.com

Chad Z. Hower aka Kudzu <c...@hower.org> wrote in message
news:Xns930BB97E6BDD6cpub@127.0.0.1...

You should ignore Kudzu - he knows nothing....

Rgds,
Martin :)

OK, thanks all!

One more question:
If I leave the connection open from a Client to the Server, than what is the
best way to enable the Client to read commands from the Server?

Something like a simple (a Timer component in app thread) OnTimer event
every x seconds (to see if there are commands from the server), or something
like a separate TThread that listens? Are there any special components in
Indy that are designed just for that?

.............................................
Zarko Gajic, BSCS
About Guide to Delphi Programming
http://delphi.about.com
.............................................

"Chad Z. Hower aka Kudzu" <c...@hower.org> wrote in message
news:Xns930BB97E6BDD6cpub@127.0.0.1...

Yes, you can just have a regular TTimer component that fires every
200-xxx ms (milliseconds), and within that timers event you can do a

Ttcpclient.Readln('',5)

make sure that if you use this method, that you encapsulate this readln
inside of a try/except/finally block like so:

try
   try
     TtcpClient.Readln('');
   except
      <some error processing here>
   end;
finally
   <some processing here if all went well in the Readln>
end;

The problem with this method, is you have to place indys 'TidAntiFreeze'
component on your main form so that "freezing" of you applicatiions GUI
will not happen when waiting for data via the Readln.  This is due to
your main VCL thread being tied up waiting for readln timeout to occur.

If you think you are a novice/advanced delphi developer, then i
recommend asking Martin James for his threaded technique of retreiving
data within a seperate thread.  His way is a more advanced way of multi
threading that doest use the infamous Synchronize method for updating
controls from within the "main" VCL thread.

hth

--
Jack Mays

news:3e2f413a$1@newsgroups.borland.com...
bandwidth.

Yes.  I makes me shudder sometimes when I hear of developers using
UDP broadcast & forwarding through routers.  If I ever tried anything
like that at the places I've worked at, I would be fired.

My servers are text-based, so I do not do 'keep-alive' by default, in
case a manual user on a Unix box has telnetted in & does not support
it.  If the client is another of my apps, it sends a single null,
(#0) if it has received nothing from the server for 10 seconds,
(default - configurable).  If it receives nothing after the next 10
sec. it disconnects.  This is easily done in the client thread using
the read timeout.

If the server receives a #0, it turns on it's 'keep-alive-on' flag
and echoes the #0.  If keep-alive is true and it receives nothing
from the client after 15 seconds it disconnects.  Again, this is easy
to arrange using the normal read timeout and a 'waiting for
keep-alive' boolean state variable.

I know that the #0 is dwarfed in size by the IP protocol overhead and
a couple of bytes, as you use, is no great extra load.  I use #0 'cos
it's ignored by many IP protocols.

There have been some occasions when an investigation into the LAN has
been done because of unacceptable loading.  My #0's do not show up on
the sniffer bar graph at all - it's always someone else stuffing up
the LAN.

Rgds,
Martin

Zarko Gajic <http://delphi.about.com> <delphi.guide.nos...@about.com>
wrote in message news:3e2f94c3@newsgroups.borland.com...

Arrgghhh!  No!

or something

Yes - just call read/readLn in a loop in the TThread.  This will
block until data is received but this does not matter in a read
thread - the rest of your app. will continue to work OK.  You can
create a TidTCPClient in the thread contructor.   If you can handle
the received data in the thread, fine.  If you have to communicate
the data to the main VCL thread, the easiest way is to red it into a
dynamically-allocated 'new' shortString & postMessage this to the
main form & 'dispose'ing of it after use.

Rgds,
Martin