Board index » delphi » Indy TCP Client Server suggestion, please!

Indy TCP Client Server suggestion, please!

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
.............................................

 

Re:Indy TCP Client Server suggestion, please!


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

Quote
> Hi

> 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?

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)

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

> --
> .............................................
> Zarko Gajic, BSCS

Bas

Re:Indy TCP Client Server suggestion, please!


Quote
> 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)

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
.............................................

Re:Indy TCP Client Server suggestion, please!


"Zarko Gajic <http://delphi.about.com>" <delphi.guide.nos...@about.com> wrote in message
news:3e2e6503$2@newsgroups.borland.com...
Quote
> 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?

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

Re:Indy TCP Client Server suggestion, please!


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

Quote

> 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?

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

Quote

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

Bas

Re:Indy TCP Client Server suggestion, please!


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

Quote
> Bas,

> > 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)

> 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'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

Re:Indy TCP Client Server suggestion, please!


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

Quote
> So to sum things up:

> Use TCPServer (active) on each Client (no separate wait thread) and
connect
> as Client from Server as needed?

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

Re:Indy TCP Client Server suggestion, please!


Quote
"Martin James" <mjames_fal...@dial.pipex.com> wrote in message

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

Quote

> 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

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

Dan

Re:Indy TCP Client Server suggestion, please!


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

Re:Indy TCP Client Server suggestion, please!


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

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

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

Re:Indy TCP Client Server suggestion, please!


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

Quote
> "Dan F" <Da...@removeme.Bigfoot.Com> wrote in news:3e2ecb98$1
> @newsgroups.borland.com:
> > I agree, keeping the connection open is a better solution in my
opinion.

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

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

Rgds,
Martin :)

Re:Indy TCP Client Server suggestion, please!


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...

Quote
> "Dan F" <Da...@removeme.Bigfoot.Com> wrote in news:3e2ecb98$1
> @newsgroups.borland.com:
> > I agree, keeping the connection open is a better solution in my opinion.

> 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

Re:Indy TCP Client Server suggestion, please!


Quote
Zarko Gajic wrote:
> 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?

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

Re:Indy TCP Client Server suggestion, please!


Quote
Larry Clark <LCl...@Bytewiser.com> wrote in message

news:3e2f413a$1@newsgroups.borland.com...
Quote
> On this point, is there a rule of thumb about how often and in what
way
> these hello messages should be sent? As a network engineer first, I
am
> extremely sensitive to unnecessary chat on the network using up

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.

Quote
> As a programmer, it's very nice to know as soon as possible when a
> connection has been lost. I just built a Tcp client/ server
application and
> have the server sending a msg every 15 minutes to all seemingly
connected
> clients. My clients send one every minute. Each ignores the other's
message
> but it detects non working connections. Obviously the messages are
only a
> couple of bytes and these numbers I just grabbed out of the air but
it seems
> to work  ok in my implementation. Never more than a few clients
logged on at
> the same time. I'm just looking for feedback about how others are
handling
> this.

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

Re:Indy TCP Client Server suggestion, please!


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

Quote
> 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),

Arrgghhh!  No!

or something

Quote
> like a separate TThread that listens?

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

Go to page: [1] [2]

Other Threads