Cook Computing

If you use XML-RPC.NET to connect to OpenDHT at the moment you are likely to find that each request will hang for a minute or so until it times out. By trial and error I found that if you configure XML-RPC.NET to format XML-RPC request documents as a single line, calls will succeed. To do this use the XmlRpcClientProtocol UseIndentation property, e.g.

IOpenDHT proxy = (IOpenDHT)XmlRpcProxyGen.Create(typeof(IOpenDHT));
(proxy as XmlRpcClientProtocol).UseIndentation = false;
int ret = proxy.put(key, value, 10, "TestOpenDHT");

If, like me, you've not heard of OpenDHT before:

OpenDHT is a publicly accessible distributed hash table (DHT) service. In contrast to the usual DHT model, clients of OpenDHT do not need to run a DHT node in order to use the service. Instead, they can issue put and get operations to any DHT node, which processes the operations on their behalf. No credentials or accounts are required to use the service, and the available storage is fairly shared across all active clients.

This service model of DHT usage greatly simplifies deploying client applications. By using OpenDHT as a highly-available naming and storage service, clients can ignore the complexities of deploying and maintaining a DHT and instead concentrate on developing more sophisticated distributed applications.

A few days ago David Ashwood reported an XML-RPC problem when accessing a blog at WordPress. When the metaWeblog.getRecentPosts method is called, WordPress returns an invalid HTTP response.

The error message from XML-RPC.NET is "Response from server does not contain valid XML." Fiddler shows that that a valid XML-RPC response is returned in the body of the HTTP response, albeit with a trailing linefeed, but the response stream of the System.Net.HttpWebResponse instance ends with "</methodReponse" followed by the linefeed, i.e. missing the closing angle bracket. This causes the XML-RPC.NET exception. However the value returned in the Content-Length response header is several hundred bytes greater than the actual size of the XML-RPC response. You could argue that HttpWebResponse should return exactly what was sent or throw an exception to report that the content-length header was wrong, but the root cause of the problem seems to be WordPress - its returning an invalid HTTP response.

Following my previous post about Vista RSS platform support for ttl, skipHours, and skipDays, Josh Christie emailed me that the platform will also support RFC 3229 - Delta Encoding in HTTP (see here on the IEBlog). The RFC specifies a standard which allows clients to request deltas of a document, for example as generated by UNIX diff. As Josh suggests support in Vista may be the catalyst for widespread adoption of the standard. Bob Wyman has a piece on how RFC 3229 could be extended for better support of feeds.

A snippet of information about the RSS platform in Windows Vista. I was interested to know if the platform will support the RSS features which allow a feed provider to reduce load on their feed (assuming consumers are obliging): ttl, skipHours, and skipDays. The RSS 2.0 spec describes these as:

<ttl> sub-element of <channel>

<ttl> is an optional sub-element of <channel>.

ttl stands for time to live. It's a number of minutes that indicates how long a channel can be cached before refreshing from the source. This makes it possible for RSS sources to be managed by a file-sharing network such as Gnutella.

Example: <ttl>60</ttl>

skipHours

An XML element that contains up to 24 <hour> sub-elements whose value is a number between 0 and 23, representing a time in GMT, when aggregators, if they support the feature, may not read the channel on hours listed in the skipHours element.

The hour beginning at midnight is hour zero.

skipDays

An XML element that contains up to seven <day> sub-elements whose value is Monday, Tuesday, Wednesday, Thursday, Friday, Saturday or Sunday. Aggregators may not read the channel during days listed in the skipDays element.

I posted a question in a comment on this entry in the RSS Team blog and Jane Kim replied:

The sync engine respects TTL, conditional gets, skipHour, and skipDay when specified by the feed.

updatePeriod and updateFrequency from the Syndication Module are not supported.

I sometimes need to determine the version of the CLR an assembly was built against. I use the following program:

using System;
using System.Reflection;
using System.IO;

class Program
{
  static int Main(string[] args)
  {
    try
    {
      if (args.Length != 1)
        throw new Exception("usage: clrbuildver file");
      string absPath = Path.GetFullPath(args[0]);
      Assembly asmbly = Assembly.LoadFile(absPath);
      Console.WriteLine(asmbly.ImageRuntimeVersion);
    }
    catch (Exception ex)
    {
      Console.Error.WriteLine(ex.Message);
      return 1;
    }
    return 0;
  }
}

This uses the Assembly ImageRuntimeVersion property. One caveat though, according to Suzanne Cook:

By default, it's [ImageRuntimeVersion] the version that the image was compiled against. However, that's not necessarily what it will be, since compilers can be configured to put any string there.

I've been using the .NET XmlTextReader class recently so Scott Hanselman's post XmlTextReader more and more caught my attention. I noticed his use of the NameTable property. I've never used this, writing coding like this

while (reader.Read()) 
{
  if (reader.NodeType==XmlNodeType.Element && reader.Name=="foo") 
  {
      ...
  }
}

object foo = reader.NameTable.Add("foo");
while (reader.Read()) 
{
  if (reader.NodeType==XmlNodeType.Element 
    && Object.ReferenceEquals(reader.Name, foo)) 
  {
      ...
  }
}

Accord to MSDN:

Several classes, such as XmlDocument and XmlReader, use the NameTable class internally to store attribute and element names. When an element or attribute name occurs multiple times in an XML document, it is stored only once in the NameTable.

The names are stored as common language runtime (CLR) object types. This enables you to do object comparisons on these strings rather than a more expensive string comparison. These string objects are referred to as atomized strings.

I wrote some test code to check how inefficient my code has been and it turns out that use of NameTable does make a difference, for example in the order of 10% faster when testing with a 90 line XML document containing 60 matching elements. Given that this is in a test which reads the document and does nothing else, the use of NameTable is probably not going to make a significant difference to a more typical program, but because it involves very little extra code it is perhaps an optimization worth making prematurely.

I'm lucky enough to have a desk with a view.

[Taken through dirty tinted windows on a cheap camera and stitched together using MSPaint]