Valer BOCAN’s Web Log

According to MSDN Subscriptions WebLog, Visual Studio 2008 is expected this week, probably as early as… today. MSDN customers will be able to download the bits from Microsoft’s servers months ahead the official launch.

Later this month will be available the Visual Studio 2008 Team System.

UPDATE (20h30 EET): Visual Studio 2008 has been released. You can get the trial editions from http://msdn2.microsoft.com/en-us/vstudio/aa700831.aspx or the free Express editions from http://www.microsoft.com/express/

An exciting addition to .NET Framework 3.5 is the System.Net.PeerToPeer namespace, located in the System.Net.dll assembly. The new namespace provides the core building blocks for creating peer to peer (P2P) applications in .NET.

Typically, a P2P communication has three phases:

• Discovery: the process of dynamically locating peers and their associated network locations.
• Connection: establishing a network connection between peers.
• Communication: the process of passing data back and forth among peers.

The features of the System.Net.PeerToPeer namespace facilitate the discovery and connection of the peers. Communication must be performed using complementary techniques such as Sockets, HTTPWebRequest and WCF Peer Channel. The underlying technology is the Peer Name Resolution Protocol (PNRP) and it enables discovery and makes communication among peers possible by enabling serverless name resolution of any resource to a set of network endpoints. PNRP is responsible for two core tasks: publishing a PeerName for others to resolve and resolving a PeerName that was published by another peer and retrieving the associated metadata. Information about the PNRP protocol can be found on Microsoft’s website at www.microsoft.com/p2p.

Creating a Peer Name

The name of the peer can be created and registered and two ways: secured and unsecured. Secured names rely on public key cryptography and they cannot be spoofed after registration with PNRP.

or

Associating Metadata

The peer name can be have associated metadata, such as an IP address, a free-text comment and a binary blob. Metadata is handled by the PeerNameRegistration object.

If we want all local addresses to be registered with the peer name, we could use the PeerNameRegistration.UseAutoEndPointSelection and set it to true, instead of adding end points manually.

Clouds

In the PNRP context, a cloud is simply a set of computers and defines the scope to which names are published to or resolved from. When publishing a name, we need to determine which cloud (or scope) we want to publish the name to.

The current implementation of the PNRP protocol uses two clouds:

• Link-local: only other peers on the same link can resolve the name.
• Global: anyone on the Internet to resolve the name.

Publishing a Peer Name

Now that we’ve seen how to create a peer name and associate the relevant metadata, it’s time for us to publish the name with the PNRP. The code snippet below shows how it’s done:

Resolving Peer Names

Peer names registered with the PNRP can be resolved using the PeerNameResolver object. The resolving party must know the name in the first place, and then it can retrieve the associated metadata such as comments and IP endpoints. The PeerNameResolver object can be used in both synchronous and asynchronous scenarios.

In order to resolve several peer names at once, the asynchronous scenario can be used such that the call to PeerNameResolver does not block.

Sample Code

I wrote a small application that demonstrates how to asynchronously resolve peer names. You need .NET Framework 3.5 on your machine and your machine should run Windows Vista, Windows Server 2008 or Windows XP SP2. The sample code was compiled using Visual Studio 2008 Beta 2.

Another syntax twist that comes handy is the Object Initializers feature of Visual Studio 2008. What the new feature basically does is allow for a more concise initialization of class fields and properties. If we were to create several instances of the Employee class (introduced in my previous post about automatic properties), that would require several lines of code that would only perform object initialization. There is nothing wrong with this, except that the code would be verbose:

We may argue that constructors can be used for a more compact object initialization. However there are instances when we need to initialize fields or properties. The code above can be rewritten as follows:

Note that after new Employee, there are no parentheses, but a named declaration enclosed between curly braces. The syntax is flexible in that that it allows reordering of initialized fields, as well as partial initializations. In the example below I instantiated the Employee class twice, and each instance was partially initialized with a different property:

Let’s suppose that our Employee class is modified such as to have a parameterized constructor (the name and type of the parameter is not important right now, but let’s just assume we have a Boolean one). The code that initializes a class with a parameterized constructor looks like this:

Some may argue that object initializers feature is not absolutely necessary and all it does is to further complicate the syntax and make programs less readable. My personal opinion is that once this and other similar features start to appeal to the public, they will be embraced and eventually adopted by everyone. I may be on the err side, but I bet that exact thing happened when the += operator was introduced in the C language.

(3 votes, average: 5 out of 5)

 Loading …

After downloading my copy of Visual Studio 2008 Beta 2, I eagerly began to explore its new features. There is a wealth of new things to discover in what’s formerly known as Orcas and I will blog about these as I progress. The first and the most striking evidence is that Visual Studio 2008 Beta 2 is extremely fast as compared to version 2005 running on the same machine. I am very pleased with this and I can almost say that I don’t miss anymore the speed of the Pascal compilers of yesteryear.
Automatic Properties is a nice addition to the already complicated C# syntax. The idea behind automatic properties is to reduce as much as possible the amount of code for commonly employed tasks. To illustrate this, let’s suppose we need a class to hold information about an employee. We could accomplish that by declaring two member variables, as below:

By itself, this class is of no particular use, since the members are declared private and they cannot be accessed from the outside. We need to declare properties (accessors) for each member. Now, we can do this in two ways: either we write the property declaration manually or we refactor the code and use the Encapsulate Field feature, as shown below (right-click the desired variable to get the context menu):

 I took the second approach, so the code should now look as follows:

There is nothing special about this class except that it is verbose. Even though we generated most of it using an automated feature, imagine how the code would look for a class that should hold tens of properties for an employee. Such a scenario is not far-fetched so the designers at Microsoft thought of a sort of syntax twist and introduced what is now called Automatic Properties. The code below is equivalent to the previous one:

All we need to declare now are the names of the properties and the compiler takes care of the internal variable and the getter/setter definitions. The syntax of the automatic properties is natural. However, it is yet to see how useful this is going to be in the real world.

My question is: would you use this feature in your projects? Would this feature improve the overall readability of the code or will it worsen it?

(No Ratings Yet)

 Loading …