Message Queues

[ 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, SendMessage andPostMessage. 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 usingSendMessage 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 aSendMessage from within the message pumping thread, the window procedure gets called directly, that is, it doesn’t go through the message pump

[ /end snip ]

(More)

Don't be shellfish...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on TumblrEmail this to someone

[ Socket Programming in C# ]

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.

 

More Detail

 

Don't be shellfish...Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInShare on TumblrEmail this to someone