Can Windows Service be started by incoming TCP connection?

Question

I'd like to make a small Windows Service, that would be shutdown most of the time, but would be automatically activated when incoming TCP (REST?) connection comes. I do not want the service to be running 24/7 just in case (albeit that might trn to be the least evil).

There were projects porting inet.d and xinet.d to Windows, but they are all abandoned, and introducing yet another dependency for a lean program is wrong.

However by the fact they were abndoned i thought it is now a standard Windows functionality?

Service Triggers documentation seems both incomplete and self-contradictionary.

• SERVICE_TRIGGER_SPECIFIC_DATA_ITEM claims that for SERVICE_TRIGGER_TYPE_NETWORK_ENDPOINT there is

A SERVICE_TRIGGER_DATA_TYPE_STRING that specifies the port, named pipe, or RPC interface for the network endpoint.

Feels great, but totally lacks any example how to specify port and nothing but the port. But then:

• SERVICE_TRIGGER structure seems to claim there is no way to "wait" on TCP/UDP connections.

SERVICE_TRIGGER_TYPE_NETWORK_ENDPOINT - The event is triggered when a packet or request arrives on a particular network protocol.

So far so good... But then.

The pTriggerSubtype member specifies one of the following values: RPC_INTERFACE_EVENT_GUID or NAMED_PIPE_EVENT_GUID. The pDataItems member specifies an endpoint or interface GUID

Dead-end. You have no choice but either Windows-specific flavor of RPC or Windows-specific named pipes. And you can only specify GUID as a data item, not a port, as it was told above.

I wonder, which part of documentation is wrong? Can ChangeServiceConfig2 API be used for a seemingly simple aim of starting service to respond to TCP packet coming to a specific port ? If yes - how?

• there is also SERVICE_TRIGGER_TYPE_FIREWALL_PORT_EVENT but the scarce documentation seems to say the functionality is the opposite, the trigger is not remote packet incoming from a client, but instead by a local server binding to a port.

---

Some alternative avenues, from quick search:

Internet Information Server/Service seems to have "Windows Process Activation Service" and "WWW Publishing Service" components, but adding dependency upon heavy IIS feels wrong too. It also can interfere with other HTTP servers (for example WAMP systems). Imagining explaining to non-techie persons how to diagnose and resolve clashes for TCP ports makes me shiver.

I wonder if that kind of starting a service on demand can be done only programming http.sys driver without rest of IIS, though.

COM protocol seems ot have servers activation on demand feature, and hopefully so does DCOM, but I do not want to have DCOM dependency. It seems today much easier to find documentation, programs and network administrators for maintaining plain TCP or HTTP connections, than DCOM. I fear relying on DCOM would be more and more fragile in practice, just like relying on DDE.

DCOM and NT-RPC would also make the program non-portable if i later would decide to use other operating systems than Windows.

Really, starting a service/daemon on incoming network connection seems so obvious a task, there has to be out-of-the-box function in Windows?