NT Service Questions
in [Win32 Kernel]
|
From: Hector Santos on 28 Jul 2010 03:44 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
From: m on 29 Jul 2010 19:16 On a single machine, service dependencies; on multiple machines, there is no method better than polling with a backoff "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:ee6X4iiLLHA.5668(a)TK2MSFTNGP04.phx.gbl... > 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
From: Hector Santos on 30 Jul 2010 00:23 Ok m, thanks for the confirmation. m wrote: > On a single machine, service dependencies; on multiple machines, there > is no method better than polling with a backoff > > "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message > news:ee6X4iiLLHA.5668(a)TK2MSFTNGP04.phx.gbl... >> 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 > -- HLS
From: Hector Santos on 30 Jul 2010 01:51 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? m wrote: > On a single machine, service dependencies; on multiple machines, there > is no method better than polling with a backoff > > "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message > news:ee6X4iiLLHA.5668(a)TK2MSFTNGP04.phx.gbl... >> 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 > -- HLS
From: m on 1 Aug 2010 12:27
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 "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message news:#YVpss6LLHA.5624(a)TK2MSFTNGP02.phx.gbl... > 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? > > > m wrote: >> On a single machine, service dependencies; on multiple machines, there is >> no method better than polling with a backoff >> >> "Hector Santos" <sant9442(a)nospam.gmail.com> wrote in message >> news:ee6X4iiLLHA.5668(a)TK2MSFTNGP04.phx.gbl... >>> 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 >> > > -- > HLS |