Custom API requirement

Question

We are currently working on an API for an existing system.

It basically wraps some web-requests as an easy-to-use library that 3rd party companies should be able to use with our product.

As part of the API, there is an event mechanism where the server can call back to the client via a constantly-running socket connection.

To minimize load on the server, we want to only have one connection per computer. Currently there is a socket open per process, and that could eventually cause load problems if you had multiple applications using the API.

So my question is: if we want to deploy our API as a single standalone assembly, what is the best way to fix our problem?

A couple options we thought of:

• Write an out of process COM object (don't know if that works in .Net)
• Include a second exe file that would be required for events, it would have to single-instance itself, and open a named pipe or something to communicate through multiple processes
• Extract this exe file from an embedded resource and execute it

None of those really seem ideal.

Any better ideas?

Answer 1

The best solution we've come up with is to create a windows service that opens up a named pipe to manage multiple client processes through one socket connection to the server.

Then our API will be able to detect if the service is running/installed and fall back to creating it's own connection for the client otherwise.

3rd parties can decide if they want to bundle the service with their product or not, but core applications from our system will have it installed.

I will mark this as the answer in a few days if no one has a better option. I was hoping there was a way to execute our assembly as a new process, but all roads to do this do not seem very reliable.