[ snippet from code project ]
Let’s go deeper into the Win32 world. There are two fundamental Win32 API calls to access and/or modify a control,
PostMessage. There is a big difference in the way the two execute. The major difference is that
SendMessage blocks the caller till the message gets processed by the message pump whereas
PostMessage returns immediately. The subtle but important difference is that messages sent using
SendMessage aren’t queued in the message queue whereas
PostMessage messages are.
SendMessage messages are directly “sent” to the message pump. The message pump retrieves and processes messages sent using
SendMessage before looking into those in the message queue. Effectively, there are then two queues, one for
SendMessage messages and one for
PostMessage messages (which is what we call the message queue). The message pump processes all messages in the first queue before starting with the second. An interesting observation is that if code does a
SendMessage from within the message pumping thread, the window procedure gets called directly, that is, it doesn’t go through the message pump
[ /end snip ]
C# has two methods of network programming
a) TcpClient or TCPListener (which are higher level abstractions of the Socket class)
b) Socket (has more functionality than abstracted classes) – WinSock
Network Programming Strategies:
1) Threaded Server – using a pool of threads, and Accept(). This is good for a small number of connections and clients and does not scale well, because of construction/destruction of threads. Simplest model.
2) Select for Multiplexed I/O – Involves monitoring a list of connections for their state, and stripping away those that are un-readable, un-writable or with error; allowing those that remain to be used. Of course, the same problem results with a large pool of connections in the thousands, where there is thrashing in “checking” the state of the connections every so often.
3) Asynchronous Call Back – Asynchronous I/O callbacks handle incoming data and connections, thus no need to setup lists to monitor (Select()) or threads to manage (Accept()). Here threads that are pooled for the application are re-used when there is something ready for processing, and the call back method is called. When the callback method is complete, the thread is returned to the pool. Thus instead of a thread being using for an entire request, it is only used for a single operation.
I’ve been wanting this functionality for a long while, and it’s good to see it’s finally released.