Discussion:
NT Service Questions
(too old to reply)
Hector Santos
2010-07-28 07:44:21 UTC
Permalink
Folks, I am adding some new options for a RPC client (NT Service) to
connect to a RPC Service on a remote machine.

By default, the client installs itself with a dependency to the same
machine RPC service. It will (or SCM will) start the RPC server
service if not already started.

wcClient -install

The new options:

wcclient -install -server:mach_name

adds a switch to the binary to tell it which RPC server to bind and
connect to.

My question is what sort of techniques I can explore, if there is not
already a Windows method for this, in particular during restart
(reboot) times to synchronize it. i.e. the RPC Server must be started
first before any RPC client can connect to it.

Currently, when the RPC client is started as a desktop, we use a
STARTUP tool to synchronize dependences, like wait for a remote RPC
server to load by basically trying to connect to it in a loop. When
its local, we use a named kernel object to wait on before starting
clients.

When starting as NT Services, I don't see a way to do this naturally,
other than maybe adding the "connection wait" looping logic to the
clients themselves, but that cause NT service startup timeout issues.

What ideas or methods do you suggest it to synchronize multiple
client/server machines?

Thanks
--
HLS
m
2010-07-29 23:16:50 UTC
Permalink
On a single machine, service dependencies; on multiple machines, there is no
method better than polling with a backoff
Post by Hector Santos
Folks, I am adding some new options for a RPC client (NT Service) to
connect to a RPC Service on a remote machine.
By default, the client installs itself with a dependency to the same
machine RPC service. It will (or SCM will) start the RPC server service
if not already started.
wcClient -install
wcclient -install -server:mach_name
adds a switch to the binary to tell it which RPC server to bind and
connect to.
My question is what sort of techniques I can explore, if there is not
already a Windows method for this, in particular during restart (reboot)
times to synchronize it. i.e. the RPC Server must be started first before
any RPC client can connect to it.
Currently, when the RPC client is started as a desktop, we use a STARTUP
tool to synchronize dependences, like wait for a remote RPC server to load
by basically trying to connect to it in a loop. When its local, we use a
named kernel object to wait on before starting clients.
When starting as NT Services, I don't see a way to do this naturally,
other than maybe adding the "connection wait" looping logic to the clients
themselves, but that cause NT service startup timeout issues.
What ideas or methods do you suggest it to synchronize multiple
client/server machines?
Thanks
--
HLS
Hector Santos
2010-07-30 04:23:14 UTC
Permalink
Ok m, thanks for the confirmation.
Post by m
On a single machine, service dependencies; on multiple machines, there
is no method better than polling with a backoff
Post by Hector Santos
Folks, I am adding some new options for a RPC client (NT Service) to
connect to a RPC Service on a remote machine.
By default, the client installs itself with a dependency to the same
machine RPC service. It will (or SCM will) start the RPC server
service if not already started.
wcClient -install
wcclient -install -server:mach_name
adds a switch to the binary to tell it which RPC server to bind and
connect to.
My question is what sort of techniques I can explore, if there is not
already a Windows method for this, in particular during restart
(reboot) times to synchronize it. i.e. the RPC Server must be started
first before any RPC client can connect to it.
Currently, when the RPC client is started as a desktop, we use a
STARTUP tool to synchronize dependences, like wait for a remote RPC
server to load by basically trying to connect to it in a loop. When
its local, we use a named kernel object to wait on before starting
clients.
When starting as NT Services, I don't see a way to do this naturally,
other than maybe adding the "connection wait" looping logic to the
clients themselves, but that cause NT service startup timeout issues.
What ideas or methods do you suggest it to synchronize multiple
client/server machines?
Thanks
--
HLS
--
HLS
Hector Santos
2010-07-30 05:51:11 UTC
Permalink
M, how about this idea.

Rather than add the polling to each RPC client, I can create a
special SYNSERVER.EXE service whose only purpose is to do this polling
(and backoff).

When a successful connect is complete with the remote RPC Server, the
SYNSERVER.EXE will then start each RPC CLIENT services where each will
attempt naturally do its connect to the RPC server itself and its
expected to succeed.

MACH1:

RPCSERVER.EXE started as a service

MACH2:

SYNCSERVER.EXE AutoStart install, polls RPCSERVER.EXE on MACH1
RPCCLIENT1.EXE Manual Start Install, startup by SYNCSERVER.EXE
RPCCLIENT2.EXE Manual Start Install, startup by SYNCSERVER.EXE
...
RPCCLIENTn.EXE Manual Start Install, startup by SYNCSERVER.EXE

See any issue with this approach?
Post by m
On a single machine, service dependencies; on multiple machines, there
is no method better than polling with a backoff
Post by Hector Santos
Folks, I am adding some new options for a RPC client (NT Service) to
connect to a RPC Service on a remote machine.
By default, the client installs itself with a dependency to the same
machine RPC service. It will (or SCM will) start the RPC server
service if not already started.
wcClient -install
wcclient -install -server:mach_name
adds a switch to the binary to tell it which RPC server to bind and
connect to.
My question is what sort of techniques I can explore, if there is not
already a Windows method for this, in particular during restart
(reboot) times to synchronize it. i.e. the RPC Server must be started
first before any RPC client can connect to it.
Currently, when the RPC client is started as a desktop, we use a
STARTUP tool to synchronize dependences, like wait for a remote RPC
server to load by basically trying to connect to it in a loop. When
its local, we use a named kernel object to wait on before starting
clients.
When starting as NT Services, I don't see a way to do this naturally,
other than maybe adding the "connection wait" looping logic to the
clients themselves, but that cause NT service startup timeout issues.
What ideas or methods do you suggest it to synchronize multiple
client/server machines?
Thanks
--
HLS
--
HLS
m
2010-08-01 16:27:53 UTC
Permalink
In principal it should work fine. The only thing to be careful of is that
your monitoring service SYNSERVER.EXE may be able to establish a connection,
but the worker service's connection may fail (i.e. out of memory, network
congestion etc.). In this case, a retry is likely appropriate.

Effectively this design implements the same logic at a whole process level,
witch is less efficient from an OS point of view, but might be easier from a
code maintenance and operational point of view
Post by Hector Santos
M, how about this idea.
Rather than add the polling to each RPC client, I can create a special
SYNSERVER.EXE service whose only purpose is to do this polling (and
backoff).
When a successful connect is complete with the remote RPC Server, the
SYNSERVER.EXE will then start each RPC CLIENT services where each will
attempt naturally do its connect to the RPC server itself and its expected
to succeed.
RPCSERVER.EXE started as a service
SYNCSERVER.EXE AutoStart install, polls RPCSERVER.EXE on MACH1
RPCCLIENT1.EXE Manual Start Install, startup by SYNCSERVER.EXE
RPCCLIENT2.EXE Manual Start Install, startup by SYNCSERVER.EXE
...
RPCCLIENTn.EXE Manual Start Install, startup by SYNCSERVER.EXE
See any issue with this approach?
Post by m
On a single machine, service dependencies; on multiple machines, there is
no method better than polling with a backoff
Post by Hector Santos
Folks, I am adding some new options for a RPC client (NT Service) to
connect to a RPC Service on a remote machine.
By default, the client installs itself with a dependency to the same
machine RPC service. It will (or SCM will) start the RPC server service
if not already started.
wcClient -install
wcclient -install -server:mach_name
adds a switch to the binary to tell it which RPC server to bind and
connect to.
My question is what sort of techniques I can explore, if there is not
already a Windows method for this, in particular during restart (reboot)
times to synchronize it. i.e. the RPC Server must be started first
before any RPC client can connect to it.
Currently, when the RPC client is started as a desktop, we use a STARTUP
tool to synchronize dependences, like wait for a remote RPC server to
load by basically trying to connect to it in a loop. When its local, we
use a named kernel object to wait on before starting clients.
When starting as NT Services, I don't see a way to do this naturally,
other than maybe adding the "connection wait" looping logic to the
clients themselves, but that cause NT service startup timeout issues.
What ideas or methods do you suggest it to synchronize multiple
client/server machines?
Thanks
--
HLS
--
HLS
Hector Santos
2010-08-02 19:30:07 UTC
Permalink
Post by m
In principal it should work fine. The only thing to be careful of is
that your monitoring service SYNSERVER.EXE may be able to establish a
connection, but the worker service's connection may fail (i.e. out of
memory, network congestion etc.). In this case, a retry is likely
appropriate.
Good point. However, in general, I would normally lean towards this
being an extraordinary situation (especially after a clean boot up).
So RPC clients startup will be expected to be successful with a
successful SYNCSERVER startup.

But the point is well taken that a mishap can occur after the
syncserver is successful and begins to start each of the RPC clients.
I think the only possible (realistic) issue is a RPC 17xx errors
(broken communications).
See below.

From an application setup error standpoint, we tell all customers to
not enable NT Services until they are happy with their setup startup
as a desktop - so they can see all GUI diagnostic errors/warnings
popups related to configuration, etc.
Post by m
Effectively this design implements the same logic at a whole process
level, witch is less efficient from an OS point of view, but might be
easier from a code maintenance and operational point of view
The good thing here is that the all clients are single sourced with
the RPC Client/Server DLL API that does the discovery, connection and
context creation, marshalling of client communications channels, etc.

Although rare to occur (less today, more in the past), the broken RPC
communications is trapped with the DLL so this situation can be
handled in single source manner.

I like the idea because SYNCSERVER would be a service version of our
existing WCSTART.EXE deskop tool that allows operators to prepare a
dependency startup of desktop processes. Here WCSTART starts the local
RPC server or skips this if REMOTE computer name is provided and
pools/waits for RPC client connection before it begins to start the
dependency tree of processes.

So SYNCSERVER would be WCSTART with relatively changes:

- GUI removed,

- Reads the same WCSTART registry data (but this needs to be moved
to HKLM), and

- Instead of CreateProcess() it calls the SCM start service API.

Sorry for the misc details, but I am also writing this as a note to
myself to summarize the work. :)
--
HLS
m
2010-08-03 23:06:36 UTC
Permalink
Sounds like you have a solution that should work
Post by m
In principal it should work fine. The only thing to be careful of is
that your monitoring service SYNSERVER.EXE may be able to establish a
connection, but the worker service's connection may fail (i.e. out of
memory, network congestion etc.). In this case, a retry is likely
appropriate.
Good point. However, in general, I would normally lean towards this being
an extraordinary situation (especially after a clean boot up). So RPC
clients startup will be expected to be successful with a successful
SYNCSERVER startup.
But the point is well taken that a mishap can occur after the syncserver
is successful and begins to start each of the RPC clients. I think the
only possible (realistic) issue is a RPC 17xx errors (broken
communications).
See below.
From an application setup error standpoint, we tell all customers to not
enable NT Services until they are happy with their setup startup as a
desktop - so they can see all GUI diagnostic errors/warnings popups
related to configuration, etc.
Post by m
Effectively this design implements the same logic at a whole process
level, witch is less efficient from an OS point of view, but might be
easier from a code maintenance and operational point of view
The good thing here is that the all clients are single sourced with the
RPC Client/Server DLL API that does the discovery, connection and context
creation, marshalling of client communications channels, etc.
Although rare to occur (less today, more in the past), the broken RPC
communications is trapped with the DLL so this situation can be handled in
single source manner.
I like the idea because SYNCSERVER would be a service version of our
existing WCSTART.EXE deskop tool that allows operators to prepare a
dependency startup of desktop processes. Here WCSTART starts the local RPC
server or skips this if REMOTE computer name is provided and pools/waits
for RPC client connection before it begins to start the dependency tree of
processes.
- GUI removed,
- Reads the same WCSTART registry data (but this needs to be moved
to HKLM), and
- Instead of CreateProcess() it calls the SCM start service API.
Sorry for the misc details, but I am also writing this as a note to myself
to summarize the work. :)
--
HLS
Loading...