Asynchronous Communications in C#

  • Thread starter Thread starter Daniel J Rodriguez
  • Start date Start date
D

Daniel J Rodriguez

Greetings everyone!

This is a fairly broard question.. But should be enough to suffice for an
answer. Currently we are making an entreprise database server. We will be
using C# - my question is this - is Asynchronous Programming in C#
sufficient for production grade quality? If so - does anyone know where to
find out how many concurrent connections can be reached (although dependant
on their data transfered)?

Any information in regards to this would be greatly appreciated!

--
Regards,


Daniel Rodriguez
Animusoft Corporation
http://www.animusoft.com
 
Daniel J Rodriguez said:
Greetings everyone!

This is a fairly broard question.. But should be enough to suffice for an
answer. Currently we are making an entreprise database server. We will be
using C# - my question is this - is Asynchronous Programming in C#
sufficient for production grade quality? If so - does anyone know where to
find out how many concurrent connections can be reached (although dependant
on their data transfered)?

Any information in regards to this would be greatly appreciated!
Click to expand...

Neither Sql Server nor Oracle uses asyncronous I/O for client connections.
Both spawn a thread for each client connection. And Oracle doesn't even
have any asyncronous I/O on many platforms. So I'm not sure that
asyncronous I/O is even necessary.

Asyncronous I/O is necessary when you measure your clients in the thousands,
like for a web server. Database servers usually measure clients in the
hundreds, and threads will generally suffice in this range.

David

David
 
Hrmm interesting...

Here is another question then - my first attempt to handling incoming
connections for the database server was to create a thread for each
connection.. After further reading I found that the Asynchronous method used
threading itself.. It uses thread pooling to handle the requests.. Moveover,
it seemed to be more responsive than the latter..

Do you have more comments on this? I would really like to know what you
think..

Regards,

Daniel J Rodriguez
Animusoft Corporation
www.animusoft.com
 
Daniel J Rodriguez said:
Hrmm interesting...

Here is another question then - my first attempt to handling incoming
connections for the database server was to create a thread for each
connection.. After further reading I found that the Asynchronous method used
threading itself.. It uses thread pooling to handle the requests.. Moveover,
it seemed to be more responsive than the latter..

Do you have more comments on this? I would really like to know what you
think..
Click to expand...

There are 2 places you have to decide between blocking I/O with slave
threads and async I/O using thread pools. The listener and the client
session. For the listener, there's no real reason to use async I/O since
you only need one thread, and it's just simpler. So the listener just
accepts the connection and passes it off to a background thread.

For the client connections async I/O has better scalability, but at the cost
of a substantially more complicated programming model, making your system
harder to implement, instrument, manage and change. So for client sessions
I would move away from dedicated slave threads for each client only if I had
to.

David
 
I am a bit confused as to what you are trying to say.. Are you saying to use
a combination of the two? To use the slave thread to listen and then use
async to communicate between the client and server - once the connection has
been established from the listener?
 
Daniel J Rodriguez said:
I am a bit confused as to what you are trying to say.. Are you saying to use
a combination of the two? To use the slave thread to listen and then use
async to communicate between the client and server - once the connection has
been established from the listener?
Click to expand...

That's one way to go. But I would recommend to use a slave thread to listen
and a slave thread for each connection. If your connections are
short-lived, you might want to pool your slave threads to save on the
overhead of creation of new threads.

David
 
Back
Top