Valid XHTML 1.0!

Valid CSS!

Powered by PHP

Get FireFox

1&1 Internet

Archived News

Client for Microsoft NetworksFriday 28th October 2011
I spent the large part of yesterday trying to figure out a problem I had with a Windows XP virtual machine.

I could not browse the network. When clicking on "View workgroup computers", nothing happened. It was like I didn't even click it.

Trying to access servers directly with the DNS/NetBios/IP address through a UNC path failed too:

"Windows cannot find 'computer'. Check the spelling and try again..."

Trying to map a network drive had similar results. The issue was clear; there was a problem with NetBIOS resolution - this is usually something to do with NetBIOS over TCP/IP not being enabled on the network card. Without this Windows will fail miserably at using WINS or DNS to lookup names. But, there's always a but, this wasn't the case. These settings were enabled and when using the "net view computername" command-prompt command the destination share list came back instantly.

My gaze finally came down on the server side, I spent much of the afternoon sifting through the DNS, DHCP & AD servers, finding dozens of duplicated records and half-configured systems. After clearing out all the relevant entries I tried again. No avail.

A new day and a fresh approach - turn it off and on again. Well, more accurately, target the components in question and reinstall. So I uninstalled the "Client for Microsoft Networks" component from the adapter properties window. Doing this will remove the components from all adapters, and indeed the computer. I rebooted and then re-installed the client in the same window and another reboot later everything magically kicked into life.

I have no idea what caused this to break, I've got no idea what setting had been switched somewhere, but reinstalling the component did the trick. I can now browse the network again.

Not that I wanted to. Firewall firmly up now and it's all being blocked - but it's the principle.

NX Client - Missing window borderMonday 24th October 2011
Since I upgraded my Linux server to Opensuse 11.4 I've had a slight problem with my NX remote desktop setup. In that my window borders are missing.

Sometimes the remnants of the window borders can be seen; and they are fully functional (if you can remember where the buttons should be (top right etc)).

This has been really bugging me as it has a surprising impact on usability. After much searching of the vast Interweb, I tried various config tweaks to metacity and Gnome in general. All to no avail. I finally noticed that this didn't happen when I was really remote, i.e. using my laptop and a 3G connection. Which lead me to discover that running the connection in "modem" mode as oppose to LAN (or even ADSL) would solve the issue. Alas, the display becomes clunky and the updates aren't great in this mode.

I had all but given up on resolving this issue when today I happened to install the client on a new computer. Not being at home I didn't have the setup program already downloaded so I downloaded it again. I was surprised to see my borders were back - although this was from a Windows XP machine, where the ones experiencing problems have always been Windows 7.

Playing with desktop composition settings on my home computer didn't help and then it struck me. The most school boy of errors. It was nothing to do with the server setup, or my client configuration - it was just I had an out-of-date client. I downloaded the latest version and *poof* problem gone. All these years in IT, and it didn't even occur to me to update my client - when you change something else and it breaks you tend to jump to that being the cause.

The latest version of NX client can be downloaded from NoMachine.

Beta testing Battlefield 3.Tuesday 11th October 2011
Firstly, let me clarify the title. The Battlefield 3 Beta code was indeed of beta quality. Rough edges and riddled with bugs. What the Battlefield 3 Beta wasn’t, was a Beta Test. This was obvious from moment they started making testing slots available only to those who bought another product from the publisher.

A publisher doesn’t run beta tests, a publisher is not a technology firm but a media firm. Their responsibility is to drum up enthusiasm and sell the product (taking a large slice of the profits as they do so). Publishers are essentially large marketing departments that bridge the gap between the developer and the general public. Unfortunately with EA, they bridge the gap with mines and toxic chemicals. Traditionally developers may be considered incapable of talking with the money-spending public, but then look at Valve – they’ve gone and done it, and done it better than EA could ever hope to achieve. Why? Because Valve are a technology firm full of people who “get” the product and the end-user – EA on the other hand is full of media folks with trendy haircuts who understand the completely wrong market.

Beta tests are about gathering information from testers. This can vary from show-stopping bugs, minor enhancement of eureka ideas. The first thing to do when implementing a beta test is to provide a framework in to which testers can feedback. This, the other clear sign that this was no beta test. Where do I go to post my feedback? Those bugs and issues that I’ve identified (and sometimes resolved)? Yes that’s right, I ramble about it in a dark corner of the Internet on the off-chance that somebody reads it, along with the thousands of other people complaining about the very same issue.

Issue tracking isn’t complex; it doesn’t even have to cost much. The development team could have gathered a lot of valuable information from the swarms of testers by providing a bug-tracking system and employing a temp or two to provide triage and root through the inevitable duplicates.

The Game

Catastrophic marketing attempts by EA were to be expected, they’ve been failing at it for a long time and nobody expected them to do anything but. On to the game itself; every few years there is a game that makes me go "Wow", they are often accompanied by a new game engine. I certainly wow'ed when I dropped into my first skirmish at Caspian Border.

The game has evidently been geared as a sequel to Battlefield 2 and not Bad Company 2 - which makes sense; although there seems to be a lot of gamers who are expecting a polished version of Bad Company 2. I hope that DICE/EA resist their cries as it will likely result in a duller game.

The action in the game has more emphasis on strategy than BC2; with the far increased bullet damage, running across an open space guns-a-blazing doesn't cut it anymore. Still, this is no Operation Flashpoint and realism is left at the door in favour of a balanced game experience; something that DICE have a tendency to tweak with patches. More real-life tactics are required to make progress, such as supressing fire as you can be damn sure that there is somebody camped out in a bush waiting for you to make your move, and there are only so many times you can sneak round the other way before the hole is plugged.

There are several omissions too, the apparent lack of a Commander role resulting in a battlefield that is reduced to an unorganised mess of bullets with each group of people working entirely independent of each other – which often results in just two or three different multiplayer games happening in parallel on the same server, with gains only made when one group notices that there is nobody playing in a certain corner of the map and can get through uncontested. This is made more confusing by the lack of a decent map overlay, the in-game radar/map can be expanded, but it gives you no wider field of view and no real information on the terrain. There is no method of examining the map layout in or out of the game meaning you have to spend a good few hours running around the map trying not to get shot at before you know where everything is. If you’re naff at directions or orientating yourself in a 3D environment then you’re at an immediate disadvantage.

There are some new additions to the toolset, such as the mobile spawn point. Gone are the days of picking on a member of your squad to sit behind a rock behind enemy lines while the rest of you go off on suicide runs. Dropping a radio saves on all that trekking over vast terrains to get to the battle; it’s not without risks though – it only takes a marginally bright gamer to notice what’s going on and setup camp next to your radio for endless free kills.

Player classes have been tweaked, which reflects more closely what people actually play-as in the existing games. Whilst this should keep things simple the weapon load-out screens are buried under a complex menu system. Each weapon coming with a myriad of enhancements, drastically changing their effectiveness; this results in lots of wasted time reconfiguring your load out for the next few metres on the map. By the end of the beta I was using a sniper rifle as an assault weapon to great effect; resulting in lengthy reconfigurations if the need ever arose to actually snipe.

There is thermal imaging available too, something which most recent games have noticeably lacked. DICE have made attempts to reduce the effectiveness of the scope by limiting its effective range and not working in smoke etc. Even with this attempt at balancing it, it is still an immensely powerful tool; which leads on to the fundamental and major barrier to the Battlefield series of games.

Unlocks are a great way to tap into that addictive nature of humans; give a reward for sticking at it. This keeps people playing. Unfortunately this means experienced players have an unfair advantage over the newer, less-skilled players; the learning curve is made steeper by the fact that you do not have the flexible tools to apply to the situation. If you get in at the release of the game then you should be able to rank up with the masses, but drop in 6 months down the line and you'll struggle against all the snipers with thermal-imaging and silencers.


Something has to be said about the new style of interfacing. Instead of loading a game and being presented with a menu we now find ourselves with EA’s origin client and a browser plugin. You first load Origin and find Battlefield, you click to play, which launches your browser and you can then search for multiplayer games to join; once an appropriate server is found the game is then launched and you join immediately.

I can understand a media company making this move, it allows rapid deployments with no client-patches to update the server browser and of course, it’s all ‘webby’. This though presents several issues; whenever you load your browser, for Battlefield or not, another plugin is loaded – exposing your browsing session to a wide attack area for hackers, using more system resources and inevitably breaking the next time your browser is updated. Then there is the little issue of how to configure the game, with no in-game menu system you are launched straight into the heat of battle, with your controls and graphics all on default. Not to fret, you can change this from the game, but only when spawned. You shouldn’t have to worry about restarting when changing fundamental settings as you’re likely to find yourself kicked out of the server (and subsequently the middle of your configuration process) due to being idle. Being keen on freeing up resources for games, I set my game executable to disable Windows Aero features; but this is somehow magically transferred to the Origin client, meaning when I quit the game I’m thrown into an environment worryingly similar to Windows 95.
This method of interfacing with the game represents a major fail, one that I find it hard to believe that the developers have missed. Hopefully once the game is released there will be some adequate workarounds.

We seem to have taken several steps back in terms of UI with Battlefield 3. ID perfected the ability to change your game settings from a text-file which you could take about with you and drop on any computer to play how you liked. We even had colour-blind settings in BC2 but once again I have my fellow squad member shooting me in the back as he cannot tell the difference between a green squad member and a red enemy.


The Battlefield 3 beta provides a tasty insight into what is looking to be an awesome game. It is overshadowed by EAs involvement, which is to such an extent that it may make the game too frustrating to give the time-of-day. How much does increased texture resolutions mean to you? £30 and a browser plugin?

SQL concurrency and deadlockingMonday 10th October 2011
I am using a MS-SQL database to store a history of all message meta-data from business partners. The meta-data primarily provides reliable messaging (through the use of a sequence number and UUID).

In order to maintain through-put I cannot have my threads (and servers as it's a distributed environment) synchronise before checking each message. This would introduce an extremely tight bottleneck; combine this with the short timeouts the client systems have, there is a risk that data will not get processed in a timely fashion, which will trigger retries and you suddenly have a run-away blockage problem.

I had an individual Stored Proc that inserts into a message log table, and checks to see if it was a duplicate. If it is not a duplicate the proc then continues to check to see if the message was delivered in the expected order by the means of a simple counter in another table.

But as I could receive duplicate or subsequent data at the very same instant in time I needed to ensure that I didn't get things over-writing each other. To do this I used the "SET TRANSACTION ISOLATION LEVEL SERIALIZABLE" statement in my proc.

This is the most restrictive isolation level, which should block other transactions until the current one has been completed. This provides us with our processing queue and allows our locking to be done at the data level and not the application level (which means avoiding all that nasty synchronisation).

I decided the first thing to do was to check for duplicates; this ensured that the latest information was available before continuing and provided a lock on the record in question. This all worked fine for months but today we experienced a dead-lock. I wrote a test harness and battered the system with thousands of duplicate and sequential messages in parallel; all processed fine. I finally found that it was a mix of duplication and normal messages that caused the locks to get messed up (which is closer to real-life than the other attempts).

After much playing around I found that the SERIALIZABLE isolation level not to be as isolated as I expected. I had the impression that it would lock the row in question and everything else would sit patiently for it to complete. Instead on my original SELECT statement a shared lock was being obtained, following that up with an INSERT, which inevitably wanted an update lock meant that everything seized in spectacular fashion.

The fix it seems is simple.

Make your SELECT obtain an update lock:

SELECT * FROM whatever WITH (updlock) WHERE x=y;

Previous Next