I’m currently working on a small auction server for a client using The Server Framework. It’s a relatively simple server, messages come in, are validated and are then broadcast to interested parties and logged. Yesterday we shipped the first cut of the source to them and I was a bit concerned that our simple test app could thrash the server so easily. Admittedly the first cut of the code hadn’t been tuned at all and the logging implementation was fairly Mickey Mouse but I was a little concerned.
The one where I find that you can teach an old dog new tricks and almost use the ‘rocks’ word.
Just recently I’ve switched to using STLPort on two of the code bases that I’m working on. One of my clients wanted to use it because they were having some weird threading issues with the standard VC6 stl and their ’enterprise’ install of VC was too hard to patch with updated stl headers from dinkumware… (I’m starting to think that ’enterprise’ often means big, clunky, broken and incompetent, but that’s another story).
I was visiting a client on Friday to help them integrate a server we’d written for them, using The Server Framework, with some of their existing systems. We had just got everything working nicely when they mentioned, in passing, that they’d occasionally had problems with our service hanging during startup but they couldn’t reproduce it. We talked through the problem for a while and then I had an idea; I configured the service incorrectly, so that it would fail during start up and shutdown.
I’d like to do some comparative performance testing of The Server Framework against a .Net TCP/IP server, but I don’t know enough to be able to write a serious TCP/IP server in .Net. Sure, I could use TcpListener to throw together a simple server but I want something built in an efficient, async, “IIS-beating”, style.
So, if anyone knows where I could find such a beast; or if someone would like to rise to the challenge and write something, please get in touch…
I was discussing the performance of The Server Framework with someone the other day and realised that there was a reasonably easy way to speed up some types of servers.
I coded a first cut of the solution last night and, so far, it shows a small, but noticeable performance gain for no changes to functionality or code outside of the framework.
The IOCP server framework was always designed for ease of use over performance.
Back in January I was writing a TCP/IP server for a client that acted as a connection gateway. Just as this project was coming to an end we started on another project which, at first, seemed quite similar; it was a TCP/IP server that provided gateway services. Just as we were starting out with this new project I made a fairly stupid decision and, well, four months later I’ve almost finished cleaning things up…
Where did the last three days go?
I’ve been working on this project for a client since February, on and off. They had some delays which meant that hardware that I needed wasn’t ready when expected, so we slipped. Then other commitments got in the way, so we slipped. Then I decided to work around the lack of hardware and make one final push for the finish line…
That was Wednesday.
I’ve been running my main mail feeds through my POP3 code for several weeks now. All my email gets pulled from the POP3 servers into my home-brew email system, it runs through my hardcoded filters which split “bad” mail from mail that might be good and finally Outlook connects to my mail server and pulls the email from my system back into production quality code land…
Occasionally I see ‘interesting things’ and these either become the focus for swift retesting session or else find their way into FogBugz…
Today I’m doing some work for a client that involves writing some blocking sockets code to talk to one of our servers. Blocking mode fits well with the architecture of the client application they use; we’re moving the app from blocking reads on a serial port to blocking reads on a socket and jiggling the protocol it uses a bit.
Testing blocking calls is actually a bit harder than testing non blocking calls because hand cranking the mock objects so that your object under test works correctly is harder to do when your test harness is blocked in a call to read() and wont come back to you until the call times out (and the operation that you’re trying to test fails) or the read completes…
A while back I finally started on the async version of the POP3 client. It ended up as a state machine and seemed to work well. The next step was to write an async version of the mail collector that I used to pull all mail from a mailbox on a server and optionally delete it.
The synchronous version of the mail collector is a fairly simple thing. You pass it the mailbox and server details and it decides how to log in; it uses APOP if the server supports it and USER/PASS if it doesn’t.
