CODEWITHSUNDEEP
c#multithreadingsocketsiis
esskar
esskar

Reputation: 10940

Socket ReceiveAsync, Timeouts and Questions

I need to reimplement a database connection driver for some legacy cobol database for one of my customers. The way the application is built, i cannot use async/await (just leave it like that, i know it is stupid). The whole application is an ASP.NET API.

The old driver uses a c++ dll, that is included with inter-op methods. The idea behind the old system is: use one connection to the db for everything, have multiple threads send a packet and have one thread that receives the answers and delegates them to the right thread. To keep the connection alive, one needs to send some sort of ping message to database and handle its pong message.

I reimplemented that as POC in c#, have one connection, open a background thread and use AutoResetEvents to notify the right threads that the answer is ready to be processed. I set the ReceiveTimeout to 5 seconds, and while there was nobody sending data to the server, the receive timeout helped me to send the ping-message to the server.

A reason for the rewrite is, that the one-connection-solution does not scale.

So, my idea is to use a socket pool and ReceiveAsync with SocketAsyncEventArgs on the sockets. The solution works so far, but not really good. Here are some questions:

Upvotes: 1

Views: 1730

Answers (1)

Stephen Cleary
Stephen Cleary

Reputation: 456377

use AutoResetEvents to notify the right threads that the answer is ready to be processed.

May I suggest a thread-safe queue? BlockingCollection<T> or BufferBlock<T>?

I set the ReceiveTimeout to 5 seconds, and while there was nobody sending data to the server, the receive timeout helped me to send the ping-message to the server.

This is weird. I assume the entire protocol is ping-pong based, or else using a receive timeout to send messages would not work.

my idea is to use a socket pool and ReceiveAsync with SocketAsyncEventArgs on the sockets

If you can't use async/await, I would advise switching to the Begin*/End* style of asynchronous API. Going straight from synchronous to SocketAsyncEventArgs is quite a leap; SocketAsyncEventArgs is the most difficult form of socket async programming.

is there a other way then a timer to send my ping-messages

I would recommend a timer; that's the normal solution for heartbeat messages. The desired semantics should be "we want to send data at least this often". So use a timer that you can reset when sending regular messages (not receiving messages).

when using ReceiveAsync, can i still use normal Send to send data, or do i have to use SendAsync?

You should be able to use synchronous for one stream and asynchronous for the other. I've never tried this, though; all systems I've worked on are fully asynchronous.

when ReceiveAsync does not receive all required data, may i use Receive to read the rest of it, or is it better to use ReceiveAsync again for the missing data?

This question doesn't make as much sense to me. If you're asynchronously reading, you shouldn't block the calling thread.

Also, I think this question is framed from the wrong perspective. It seems like the code wants to "receive the next message", but this is a problematic way to approach reading from a socket. Instead, I recommend that your code have a loop that endlessly reads from the socket and passes that data to another type that buffers it as necessary and pushes out messages as they finish.

is this a known behaviour when debugging an IIS process under load?

I would not expect so, but I don't have much IIS load testing experience.

Upvotes: 2

Related Questions