🚀 go-pugleaf

"Lesley Anne" <mspfila-ng@yahoo.com> wrote in message
news:44f480ff@newsgroups.borland.com...

> I'm planning on adding a TIdTCPServer to one of my applications, but
> not doing anything with it except occasionally turning on or off its
Active
> property.  Another application will periodically connect to it, but no
data
> is sent between the two.

Interesting approach.  I assume that you are doing this just so that one
application can detect if the other is running?

> I know the component will allocate buffers and other resources, but
> would the fact that I don't plan on actually reading from these
connections
> ever cause problems with managing those resources?

The only problem with not doing any reading is that the server will never be
able to detect a client disconnecting.  The server needs to perform some
kind of access to the socket, otherwise the socket will just sit there
indefinately.  The server itself never checks the state of its client
connections.  Instead, it relies on the OnExecute event handler to
disconnect the sockets, or otherwise perform reading/writing operations on
the sockets so that Indy can detect disconnects at the API layer, which will
then cause the reading/writing operations to throw an exception that the
server can use to terminate the managing thread and clean up the socket.

> The port it listens on is called "DefaultPort".

Not exactly.  The server listens on the Port of each item in the Bindings
collection.  When adding a new item to the collection, the DefaultPort is
copied to the Bindings's Port property as the default value.  The Port can
then be changed on a per-item basis before the server is activated, so the
server can listen on multiple ports at a time.

> The use of the word "default" in the property's name is a bit disturbing

Only because you are thinking of it in the wrong context.  See above.

> as though it could end up listening on some other port instead.

It can.  See above.

> If you're curious, the seemingly unused connections are there for
> alarming purposes.  Whenever my application is up and running smoothly,
> it will have a server listening on a port.  Whenever it runs into
problems,
> it will shut off that port.  A separate alarming application periodically
> checks the status of all our applications by seeing whether it can connect
> to their alarming ports.  Since status is reported simply by whether or
> not connections are allowed, no further data needs to be sent.)

Are all of the applications running on a single machine?  If so, then what
you describe is not really a good use of TCP/IP sockets.  A named mutex that
is signaled during alarm conditions would probably work better.  Of course,
if you need to check applications across a network, then using TCP/IP is
best, although I would suggest not closing the port at all.  Leave it open,
and have the alarming application send a request over the connection.  The
server can then report back whether an alarm exists, and better can also
report what the details of the alarm actually are.


Gambit