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

Do you mean something like Net.TCP port sharing?

Answer 2

You could fix the client-side port while opening your socket, say 45534. Since one port can be opened by only one process, only one process at a time would be able to open socket connection to the server.

Answer 3

Well, there are many ways to solve this as expressed in all the answers and comments, but may be the simpler way you can use is just have global status store in a place accesible for all the users of the current machine (may be you might have various users logged-in on the machine) where you store WHO has the right to have this open. Something like a "lock" as is used to be called. That store can be a field in a local or intranet database, a simple file, or whatever. That way you don't need to build or distribute extra binaries.

Answer 4

When a client connects to your server you create a new thread to handle him (not a process). You can store his IP address in a static dictionary (shared between all threads). Something like:

static Dictionary<string, TcpClient> clients = new Dictionary<string, TcpClient>();

//This method is executed in a thread
void ProcessRequest(TcpClient client)
{
   string ip = null;
   //TODO: get client IP address

   lock (clients)
   {
      ...
      if (clients.ContainsKey(ip))
      {
         //TODO: Deny connection
         return;
      }
      else
      {
         clients.Add(ip, client);
      }
   }
   //TODO: Answer the client
}
//TODO: Delete client from list on disconnection

Answer 5

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.