Duplicate client/server programs.

[TomChapman]

I have written a program that is installed and runs on two different
servers on our network. Amongst other things the two programs talk to
each other using a TCP connection. I configure one of the programs to be
the TCP server and the other to be the TCP client. They then connect up
to each other and talk with each other.

The two programs are identical except for the configuration designating
one a TCP server and one a TCP client. So when we install these programs
on new servers pairs, we have to remember to designate one a server and
one a client.

I was wondering if there was some other way to handle designating the
server or client aspect? Is there some method people have used?

[ralph]

On Sun, 05 Feb 2012 15:52:21 -0600, TomChapman

Post by TomChapman
I have written a program that is installed and runs on two different
servers on our network. Amongst other things the two programs talk to
each other using a TCP connection. I configure one of the programs to be
the TCP server and the other to be the TCP client. They then connect up
to each other and talk with each other.
The two programs are identical except for the configuration designating
one a TCP server and one a TCP client. So when we install these programs
on new servers pairs, we have to remember to designate one a server and
one a client.
I was wondering if there was some other way to handle designating the
server or client aspect? Is there some method people have used?

Not clear what you mean by this "pre-configuring" before it is
installed. Is this something hard-coded?

Recode the program to accept its role from a command line option.
Make that option a part of the installation process.

-ralph

[Richard Norman]

Post by ralph
On Sun, 05 Feb 2012 15:52:21 -0600, TomChapman

Post by TomChapman
I have written a program that is installed and runs on two different
servers on our network. Amongst other things the two programs talk to
each other using a TCP connection. I configure one of the programs to be
the TCP server and the other to be the TCP client. They then connect up
to each other and talk with each other.
The two programs are identical except for the configuration designating
one a TCP server and one a TCP client. So when we install these programs
on new servers pairs, we have to remember to designate one a server and
one a client.
I was wondering if there was some other way to handle designating the
server or client aspect? Is there some method people have used?

Not clear what you mean by this "pre-configuring" before it is
installed. Is this something hard-coded?
Recode the program to accept its role from a command line option.
Make that option a part of the installation process.

To provide for proper startup with untrained (or incompetent)
operators, this is easily done by stashing away the actual program
somewhere not easily visible but providing a batch (or .cmd) file with
the proper command line.

Alternatively, the installation procedure could put the distinction on
which mode to execute into an initialization file or into the
registry.

[ralph]

On Sun, 05 Feb 2012 18:45:08 -0700, Richard Norman

Post by Richard Norman

Post by ralph
On Sun, 05 Feb 2012 15:52:21 -0600, TomChapman

Post by TomChapman
I have written a program that is installed and runs on two different
servers on our network. Amongst other things the two programs talk to
each other using a TCP connection. I configure one of the programs to be
the TCP server and the other to be the TCP client. They then connect up
to each other and talk with each other.
The two programs are identical except for the configuration designating
one a TCP server and one a TCP client. So when we install these programs
on new servers pairs, we have to remember to designate one a server and
one a client.
I was wondering if there was some other way to handle designating the
server or client aspect? Is there some method people have used?

Not clear what you mean by this "pre-configuring" before it is
installed. Is this something hard-coded?
Recode the program to accept its role from a command line option.
Make that option a part of the installation process.

To provide for proper startup with untrained (or incompetent)
operators, this is easily done by stashing away the actual program
somewhere not easily visible but providing a batch (or .cmd) file with
the proper command line.
Alternatively, the installation procedure could put the distinction on
which mode to execute into an initialization file or into the
registry.

Like that too.

The key is instead of a two step process - "configuration" then
"installation" - make it all part of a single install process.

-ralph

[BobF]

Post by ralph
On Sun, 05 Feb 2012 18:45:08 -0700, Richard Norman

Post by Richard Norman

Post by ralph
On Sun, 05 Feb 2012 15:52:21 -0600, TomChapman

Post by TomChapman
I have written a program that is installed and runs on two different
servers on our network. Amongst other things the two programs talk to
each other using a TCP connection. I configure one of the programs to be
the TCP server and the other to be the TCP client. They then connect up
to each other and talk with each other.
The two programs are identical except for the configuration designating
one a TCP server and one a TCP client. So when we install these programs
on new servers pairs, we have to remember to designate one a server and
one a client.
I was wondering if there was some other way to handle designating the
server or client aspect? Is there some method people have used?

Not clear what you mean by this "pre-configuring" before it is
installed. Is this something hard-coded?
Recode the program to accept its role from a command line option.
Make that option a part of the installation process.

To provide for proper startup with untrained (or incompetent)
operators, this is easily done by stashing away the actual program
somewhere not easily visible but providing a batch (or .cmd) file with
the proper command line.
Alternatively, the installation procedure could put the distinction on
which mode to execute into an initialization file or into the
registry.

Like that too.
The key is instead of a two step process - "configuration" then
"installation" - make it all part of a single install process.
-ralph

Make sure you prompt for confirmation,

"Are you SURE you want this to run as a CLIENT? (Y/N)"

:-) Sorry, couldn't resist ...

[ScottMcP [MVP]]

One way is to let the two programs discover each other using a named
pipe. With your unique pipe name, check at program start for the
existence of the pipe. (Use CreateFile with the pipe name.) If the
pipe is not found then assume you are the server and use
CreateNamedPipe to establish the pipe so the other computer will find
it later.

[Mark Robinson]

Post by TomChapman
I have written a program that is installed and runs on two different
servers on our network. Amongst other things the two programs talk to
each other using a TCP connection. I configure one of the programs to be
the TCP server and the other to be the TCP client. They then connect up
to each other and talk with each other.
The two programs are identical except for the configuration designating
one a TCP server and one a TCP client. So when we install these programs
on new servers pairs, we have to remember to designate one a server and
one a client.
I was wondering if there was some other way to handle designating the
server or client aspect? Is there some method people have used?

If you tell each program what the IP address of the other program is,
then you could just code some convention based on IP address - lowest
numbered IP becomes the server, or whatever. Since each side will know
both its own IP and the other program's IP, they should agree.

Alternatively, since the programs are identical they each contain both
server and client code. So, simply have the programs both start servers
and both start a client to connect to the other's server. When both are
connected, negotiate which end becomes the server somehow (virtual coin
toss).

Cheers

mark-r