Question

Most people seem to build a listener socket and will include “events” to be invoked for processing. EG: SocketConnected, DataReceived. The programmer initializes a listener and binds to the “events” methods to receive socket events to build the service.

I feel on a large scale implementation, it would be more efficient to avoid delegates in the listener. And to complete all the processing in the callback methods. Possibly using different call backs for receiving data based on the knowledge of knowing what command is coming next. (This is part of my Message Frame Structure)

I have looked around for highly scalable examples, but I only find the standard MSDN implementations for asynchronous sockets or variations from other programmers that replicate the MSDN example.

Does anyone have any good experience that could point me in the right direction?

---

Note> The service will hold thousands of clients and in most cases, the clients stayed connected and updates received by the service will be send out to all other connected clients. It is a synchronized P2P type system for an object orientated database.

Answer 1

The difference between an event call and a callback is negligible. A callback is just the invocation of a delegate (or a function pointer). You can’t do asynchronous operation without some sort of callback and expect to get results of any kind.

With events, they can be multicast. This means multiple callback calls–so that would be more costly because you calling multiple methods. But, if you’re doing that you probably need to do it–the alternative is to have multiple delegates and call them manually. So, there’d be no real benefit. Events can often include sender/eventargs; so, you’ve got that extra object and the creation of the eventargs instance; but I’ve never seen a situation where that affected performance.

Personally, I don’t use the event-based asynchronous pattern–I’ve found (prior to .NET 4.5) that the asynchronous programming model to be more ubiquitous. In .NET 4.5 I much prefer the task asynchronous pattern (single methods that end in Async instead of two methods one starting with Begin and one starting with End) because they can be used with async/await and less wordy.

Now, if the question is the difference between new AsyncCallback(Async_Send_Receive.Read_Callback) e.g.:

s.BeginReceive(so.buffer, 0, StateObject.BUFFER_SIZE, 0, 
                                     new AsyncCallback(Async_Send_Receive.Read_Callback), so);

and just Async_Send_Receive.Read_Callback e.g.:

s.BeginReceive(so.buffer, 0, StateObject.BUFFER_SIZE, 0, 
                                     Async_Send_Receive.Read_Callback, so);

The second is just a short-hand of the first; the AsyncCallback delegate is still created under the covers.

But, as with most things; even if it’s generally accepted not to be noticeably different in performance, test and measure. If one way has more benefits (included performance) than another, use that one.