Thanks to Ned Batchelder for pointing out the “discussion” about the pros and cons of multi-threaded programming over on the SQLite newsgroup. The comments on Ned’s post are well worth reading; they’ve provided me with a new blog to subscribe to, Jeff Darcy’s Canned Platypus which seems to have lots of the kind of high quality techie stuff that I like.
My view on multi-threading is probably pretty obvious given the way my socket server framework is designed…
I’m currently adding some functionality to a server that I wrote, using The Server Framework, for a client last year. The server provides application gateway services for them. The new functionality is to switch to using asynchronous connect calls using ConnectEx when it’s available on the platform that the server is running on and to continue to use a blocking connect if ConnectEx isn’t available.
As I mentioned in the posting back in Feb 2004 the performance counters that we add to these kinds of servers are invaluable in tracking down problems.
There’s a rather disappointing article on .Net sockets in this month’s MSDN magazine.
Updated 5th May 2023 to fix broken links
The title of the piece is “Get Closer to the Wire with High-Performance Sockets in .NET” which nicely over-hypes the content. How, exactly, am I getting closer to the wire by placing a managed layer between my code and the wire? The summary box is a little more honest; describing the article as covering “basic socket programming” and “factors in creating socket-based servers” which it does…
Having got the CMessageProcessor under test in the last posting. I added a few easy tests for the object and then I came to another hard to add test. The reason that it was hard to add was that the object is doing a little too much.
The easy to add tests were for the object’s Initialise() and Shutdown() functions; though whilst adding the tests I made a note to see if I could do away with the functions in the near future.
I’ve just started work on an ISO8583 server for a client. I’ve done similar work for them in the past and the first thing that I did was to take the basic shell of the last server that I did for them and update it to use all of latest version of The Server Framework. The next was to start to look at the first of the requirements for the new server.
I’m updating one of the pieces of sample code that we put on CodeProject a couple of years ago. A client wants a version of the COM object socket server that has been built with the latest version of our server framework and which supports outbound connections as well as inbound. The work has been going reasonably well until this afternoon when I found I had a problem shutting down the socket connections that I’d opened.
Bob Etheridge reported a bug in the socket server code from codeproject, this is probably the oldest version of The Server Framework’s Free Framework code. He was noticing a small amount of memory corruption on server shutdown. I’ve narrowed it down to a bug in the CThreadPool class in the Win32 tools library. The bug is present in all versions of the class.
void CThreadPool::ThreadStopped(WorkerThread *pThread) { ::InterlockedDecrement(&m_activeThreads); ::InterlockedDecrement(&m_initialisedThreads); RemoveThreadFromList(pThread); OnThreadStopped(); } Should actually be
I’ve just about finished the auction server performance tuning. Our thrash test that uses 200 concurrent clients all responding to every bid with a counter bid has gone from averaging 40 incoming bids per second and 3700 outgoing bids per second to 180 incoming and 18000 outgoing. The peak incoming and outgoing were nearer to 1600 and 52000… I’m pretty pleased with the improvements and eventually decided to put the thoughts of lock free list traversal on hold, we don’t need it.
I’m currently looking at “lock free” access to the linked list that stores the set of clients to communicate with. Ideally we’ll be able to add to, delete from and traverse the list from multiple threads without needing to lock and synchronise. There are lots of references available, so far these two (1 and 2) look good from a quick scan of them whilst they were printing… Wish I’d kept up my ACM membership as it looks like the definitive works are available as conference proceedings on their site (then again, I often find that the definitive work isn’t necessarily the best starting point).
I’m currently working on a simple auction server for a client using The Server Framework. You can think of it as a specialised chat server, of sorts. One of the things it must do is broadcast messages from one user to a set of users. This is relatively easy to implement in a crude way in The Server Framework but it’s not nice. Time to refactor towards niceness…
The lack of niceness in the quick and dirty implementation of broadcast messages is the fact that the message must be duplicated for each client that will receive the broadcast.
