C＃中具有异步TCP侦听器的多个客户端

Question

I have a problem with async TCP listener in C#. The main problem is I want to create async TCP listener in order to handle multiple connections. I have tons of requests from devices and webpages. Also I have to use database to write specific information from these connections (read/write to/from SQL Server).

The scenario of our task is this: One REST request will post from a webpage with a unique identifier to our Web API. Then our Web API makes a TCP connection to our listener, so we must halt this connection until we get another connection from a device with that unique identifier. Then we send data which we got it before (webpage connection) to this connected device and again we must halt this connection too. After processing this data in the device it will send us some other data again, and we must send this data to webpage which we halted it before.

How can I find halted connection in our listener?

Is there a better solution for us? (except using async TCP listener)

Because of some customer reasons we are unable to use signalR or self-hosted Web API in C#.

Regards, Sara

Answer 1

'Halt' isn't the best word to describe what you need. If you need two-way communication with a web page over a REST request, you simply need to keep that request pending until the response is ready (not recommended, it could take really long and the connection could be dropped due to network conditions). Do reconsider your choice of avoiding SignalR. However, if need be, you can keep the request thread waiting. To do that, you'd need either a TaskCompletionSource (if you're processing the request within a Task) or a synchronization primitive such as a ManualResetEvent . I can't really give you more details without knowing the conditions your code will run under.

On the device side of things, again you need two way communication. You could implement this in one of two ways:

1. The device opens a TCP connection and keeps it open. The server receives the ID, and then sends the data back over the connection. The device then processes this data in some way and sends its response back to the server over the same connection and terminates the connection.

2. The device makes the equivalent of a REST GET request to the server to grab the data from the web page. It then processes the data and makes the equivalent of a POST request to send its own data back to the server.

After this is done, you still have the connection from the web page waiting for a response. Simply let it know the transaction has completed, using TaskCompletionSource.SetResult or ManualResetEvent.Signal . The server can then write whatever data it needs in the response to the web page's request and close that connection too.

Also note that there is no such thing as a halted connection. You just intentionally delay writing a response.

---

EDIT: You can't really hold the connection (not with the normal execution flow of most web servers at least), but you can stop the thread processing that connection. This is a heavily simplified (and completely inappropriate for any real system) example:

// ConnectionManager.cs
public static Dictionary<Guid, TaskCompletionSource<DataToSendToWebPage>> connectionTCSs;

// WebPageRequestHandler.cs
async Task HandleClientRequest() {
    // do some stuff
    var tcs = new TaskCompletionSource<DataToSendToWebPage>();
    ConnectionManager.connectionTCSs[deviceID] = tcs;
    var result = await tcs.Task; // This is where you wait for the other flow to complete
    // Write response to connection
}

// DeviceRequestHandler.cs
void HandleRequest() {
    // do stuff
    ConnectionManager.connectionTCSs[clientID].SetResult(result);
}

The general idea is that you keep the thread (or task) processing the web page request waiting, and then signal it to continue from the other thread when the device's connection is handled and data is received.