views:

756

answers:

5

I'm looking to move a Windows C++ application to C# so that some major enhancements are a bit easier. The C++ application is single-threaded and uses a home-grown reactor pattern for all event handling of accepting, reading and writing sockets, and timers. All socket handling is done async.

What is the accepted way to implement a C# reactor pattern? Are the existing libraries?

+2  A: 

.NET Threads, Sockets and Event Handling have first class support within C# and .NET, so the need for an external library is pretty light. In otherwords, if you know what you are doing, the framework makes it very straight forward to roll your own socket event handling routines.

Both companies I work for, tended to reuse the default .NET Socket library as is for all network connections.

Edit to add: Basically what this means is this is an excellent opportunity to learn about Delegates, Events, Threads, and Sockets in .NET/C#

Alan
+2  A: 

brofield,

Unfortunately the mentality of the C# world is still in the thread per connection realm. I'm looking for a way to handle multiple connections on a single Compact Framework/ Windows CE box and looking to write my own Proactor/Reactor pattern (fashioned after the one used in ACE) Compact Framework doesn't seem to support asynch connecting - just asynch reading and writing. I also need to manage tight control over timeouts (soft realtime application).

Alan,

One reason to implement a proactor/reactor pattern is so that you don't have to have a thread running for each connection. A web server is the classic example. A busy server could easily have 100s of connections active at anyone time. With that many threads (and I've seen implementations that have one thread to read, another to write data) the time spent in a context switching becomes significant. Under Windows CE on a 750Mhz ARM processor, I measured over a millisecond with peaks as high as 4 milliseconds.

I still find most C# and Java applicatons that I've come across still have way too many threads running. Seems to be the solution for everything - start another thread. Example. Eclipse (the IDE) use 44 threads even before I actually open a project. 44 threads???? to do what exactly??? Is that why Eclipse is so slow?

+2  A: 

Have a read of Asynchronous Programming in C# using Iterators;

In this article we will look how to write programs that perform asynchronous operations without the typical inversion of control. To briefly introduce what I mean by 'asynchronous' and 'inversion of control' - asynchronous refers to programs that perform some long running operations that don't necessary block a calling thread, for example accessing the network, calling web services or performing any other I/O operation in general.

Steve Cooper
+1  A: 

The Windows kernel has a very nice asynchronous wait API called I/O Completion Ports, which is very good for implementing a reactor pattern. Unfortunately, the System.Net.Sockets library in the .NET framework does not fully expose I/O Completion Ports to developers. The biggest problem with System.Net.Sockets is that you have no control over which thread will dequeue an asynchronous completion event. All your asynchronous completions must occur on some random global .NET ThreadPool thread, chosen for you by the framework.

James Brock
A: 

The Reactive Extensions library for .net may be the sort of thing you are looking for.

Steve Gilham