Hashemian Blog

Web Tools, Financial Markets, Technology

Sunday, June 29, 2008

RSS/ATOM SyndicationFeed in .NET 3.5 Framework

Among some of the new classes introduced in Version 3.5 of the .NET Framework Class Library (FCL) were the syndication-related classes. While other technologies such as LINQ, extension methods and lambda expressions have been grabbing most of the attention the new syndication classes also deserve a nod. Part of the System.ServiceModel.Syndication namespace the classes offer a variety of methods to easily generate or consume syndication feeds in RSS 2.0 or ATOM 1.0 formats.

It's not that reading or writing feeds were exceedingly difficult before. FCL comes with a number of XML classes that facilitate working with XML data which all syndication feeds emanate from. No doubt there are plenty of sample code out there that made the task as easy as copy, paste and tweak. But now FCL comes with its own native classes to handle feeds, with advanced settings, intellisense, and potential of extension.

To demonstrate ease of use, here's a sample code that pulls in a sample feed from Google, and scrapes and saves the content of each link to a file:

var wc = new WebClient();
using (var rss = XmlReader.Create(
       "http://finance.google.com/finance?morenews=10&q=NASDAQ:INTC&output=rss")) {
  var feed = SyndicationFeed.Load(rss);
  foreach (var x in feed.Items) {
    var uri = x.Links.Last().Uri;
    wc.DownloadFile(uri, @"c:\rss\" + Regex.Replace(uri.LocalPath, @"^.*/", ""));
  }
}

That was easy, eh? Just remember to add System.ServiceModel.Web.dll as a reference to your project. Happy syndicating.

rss,atom,microsoft,net,asp.net,xml

Labels: programming

// posted by rh

0 comments

Wednesday, June 18, 2008

DNS Mystery, NameServers, IP addresses

Today I was trying to reach 1&1's home page, but the browser kept failing to pull up the site. Mysteriously I was able to reach 1&1's home page when I changed my DNS servers to those of OpenDNS.org. Feeling curious I decided to investigate the matter in depth. My default DNS server was reporting the IP address of www.1and1.com to be 217.160.232.1. While that address belongs to 1&1, it's really one of their routers or gateways and not a Web server. No wonder I was unable to access the site. the working IP address reported by OpenDNS.org and a number of other DNS servers was 217.160.226.203. That is indeed the correct IP address for www.1and1.com. So why was I seeing different results from different DNS servers?

As you may know the job of translating a host name to an IP address falls on a program known as the resolver which queries its designated DNS server for the answer. If the DNS server can not produce the translation (from its cache or authority zone), it issues what it's know as a recursive query to the DNS network on the Internet. The host name is broken to its fragments and each fragment from right to left is queried successively. The results generally consists of hosts known as NameServers, which get the query one step closer to the final result. The final NameServers produce the IP address translation. However, if any of the NameServers along the way can produce the translation, the query stops and the IP address is sent back to the resolver.

Using the Unix/Linux dig command I followed the name resolution for www.1and1.com one step at a time. Results are shown here and shortened for brevity.

This command displays the root servers:

# dig
;; ANSWER SECTION:
.                       451081  IN      NS      M.ROOT-SERVERS.NET.
.                       451081  IN      NS      A.ROOT-SERVERS.NET.
.                       451081  IN      NS      B.ROOT-SERVERS.NET.
.                       451081  IN      NS      C.ROOT-SERVERS.NET.

This command queries one of the root servers and produces NameServers for "com." TLD (Top Level Domain):

# dig +norec @A.ROOT-SERVERS.NET www.1and1.com
;; AUTHORITY SECTION:
com.                    172800  IN      NS      K.GTLD-SERVERS.NET.
com.                    172800  IN      NS      L.GTLD-SERVERS.NET.
com.                    172800  IN      NS      M.GTLD-SERVERS.NET.
com.                    172800  IN      NS      A.GTLD-SERVERS.NET.

This command queries one of the "com." NameServers:

# dig +norec @A.GTLD-SERVERS.NET www.1and1.com
;; ANSWER SECTION:
www.1and1.com.          172800  IN      A       217.160.232.1
;; AUTHORITY SECTION:
1and1.com.              172800  IN      NS      ns27.1and1.com.
1and1.com.              172800  IN      NS      ns28.1and1.com.

Generally the previous command shouldn't produce and IP address, instead the authority section would prompt a final query to one of the 1and1.com NameServers (which by the way have the correct IP translation.) Instead somehow an IP address is produced at this level and the query ends with this inaccurate IP translation. I've tried the same query with the homepage URL's of Microsoft, Google, Yahoo and a few other sites and none return an IP address at this level.

It remains to be seen if this erroneous translation would eventually spread around, causing 1&1's homepage to become widely inaccessible. Anyone knows how that IP translation ended up in of the "com." NameServers? Am I making wrong assumptions here? Feel free to let me know.

dns,nameservers,domain names,ip addresses,internet

Labels: internet, networks, web

// posted by rh