WebDAV and Windows - Part I

Using WebDAV on Windows has become more secure but consequently a little less developer friendly in recent years. Being aware of the following points makes the experience much easier:

• By default, Microsoft now disables WebDAV mapping when using Basic Authentication over HTTP ie without SSL. Developers and users have two options:
• Enable WebDAV with Basic Authentication without SSL (its unsecure and you should avoid it)
• Enable SSL encryption for your WebDAV server (if you're going to use self-signed certificates, make sure you are aware of some related caveats)
• With Windows Explorer its easy to map a WebDAV folder (Add a Network Location). However, the GUI approach can leave users confused with the results, because it doesn't expose all the nasty error messages lurking under the covers. Its best therefore to simply use the following commands to map and unmap respectively:
• net use * https://:/ /user: * /persistent:no
• net use * /delete

 

Self-Signed Certificates 

• Your certificate will need to be imported into the Windows Trusted Certificate store before you can start using your SSL encrypted WebDAV share 
• Your certificate will need to have a Subject Alternate Name (SAN) for it to be acceptable for most purposes. If you're using the Java keytool for example, here is a key generation invocation that worked for me:
• keytool -genkey -keyalg RSA -alias selfsigned -keystore my.keystore -storepass 1234 -keypass 1234 -validity 360 -keysize 2048 -ext SAN=dns:swiftsense.com,ip:192.168.1.73,dns:localhost,dns:www.swiftsense.biz

Apple Bonjour Pitfalls on Multicore Machines

Many in the software development community rejoiced when Apple announced they were open sourcing Bonjour. I am not ashamed to say I was one of them since I have used the technology in my own projects and have been amazed by the relative ease of use of the technology as compared to something like Jini. However, a problem we ran into recently highlighted some of the unforeseen hiccups technology can run into -

My Bonjour based auto-discovery code written using the new Java libraries was working very reliably in test environments for some time. In fact, we could test it even on VMWare. However, we ran into trouble when some of the non-virtual test machines started displaying erratic auto-discovery behaviour - specifically, discoverable components would not be discovered, or if discovered would soon be spontaneously lost, etc.

Much testing and debugging followed before we narrowed down our problem to the fact that it happened only on multicore machines - Dell Latitude D620s in fact. On Dell Latitude D810s, or any other single core CPU, the applications behaved as expected .

Then we found that the BrowserApp that comes with the 1.0.3+ SDK samples, has similar erratic behaviour on the same machines - and in fact consistently refused to detect nodes on the network. And then most interestingly, we found that the dns-sd.exe program (written in C) based on the same low level libraries that the Java libraries depend on, works perfectly, irrespective of the CPU!!

This seemed to indicate that the Java code we had written modeled on Apple's sample code had inherited some problems from it. Eventually with some re-reading of their documentation and a better understanding of the event based API that Apple provides, we managed to rewrite our Java application so that it too worked as expected.

However, the whole experience suggests that chip manufacturers may be pushing software development to a whole new era of implicit multi-threading with a host of associated issues, that many software developers are just not ready for.