Remoting in .NET

Remoting in .NET
Introduction:
Distributed computing is an integral part of almost every software development. Before .Net Remoting, DCOM was the most used method of developing distributed application on Microsoft platform. Because of object oriented architecture, .NET Remoting replaces DCOM as .Net framework replaces COM.
Benefits of Distributed Application Development:
Fault Tolerance: Fault tolerance means that a system should be resilient when failures within the system occur.
Scalability: Scalability is the ability of a system to handle increased load with only an incremental change in performance.
Administration: Managing the system from one place.
In brief, .NET remoting is an architecture which enables communication between different application domains or processes using different transportation protocols, serialization formats, object lifetime schemes, and modes of object creation. Remote means any object which executes outside the application domain. The two processes can exist on the same computer or on two computers connected by a LAN or the Internet. This is called marshalling (This is the process of passing parameters from one context to another.), and there are two basic ways to marshal an object:
Marshal by value: the server creates a copy of the object passes the copy to the client.
Marshal by reference: the client creates a proxy for the object and then uses the proxy to access the object.
Comparison between .NET Remoting and Web services:
For performance comparison between .Net Remoting and ASP.Net Web Services Click.
Architecture:
Remote objects are accessed thro channels. Channels are Transport protocols for passing the messages between Remote objects. A channel is an object that makes communication between a client and a remote object, across app domain boundaries. The .NET Framework implements two default channel classes, as follows:
HttpChannel: Implements a channel that uses the HTTP protocol. TcpChannel: Implements a channel that uses the TCP protocol (Transmission Control Protocol). Channel take stream of data and creates package for a transport protocol and sends to other machine. A simple architecture of .NET remoting is as in Fig 1.
As Fig.1 shows, Remoting system creates a proxy for the server object and a reference to the proxy will be returned to the client. When client calls a method, Remoting system sends request thro the channel to the server. Then client receives the response sent by the server process thro the proxy.
Example:
Let us see a simple example which demonstrates .Net Remoting. In This example the Remoting object will send us the maximum of the two integer numbers sent.
Creating Remote Server and the Service classes on Machine 1: Please note for Remoting support your service (Remote object) should be derived from MarshalByRefObject.
using System;using System.Runtime.Remoting.Channels; //To support and handle Channel and channel sinksusing System.Runtime.Remoting;using System.Runtime.Remoting.Channels.Http; //For HTTP channelusing System.IO;namespace ServerApp{public class RemotingServer{public RemotingServer(){//// TODO: Add constructor logic here//}}//Service classpublic class Service: MarshalByRefObject {public void WriteMessage (int num1,int num2) {Console.WriteLine (Math.Max(num1,num2));}}//Server Classpublic class Server{public static void Main () {HttpChannel channel = new HttpChannel(8001); //Create a new channelChannelServices.RegisterChannel (channel); //Register channelRemotingConfiguration.RegisterWellKnownServiceType(typeof Service),"Service",WellKnownObjectMode.Singleton); Console.WriteLine ("Server ON at port number:8001");Console.WriteLine ("Please press enter to stop the server.");Console.ReadLine ();}}}
Save the above file as ServerApp.cs. Create an executable by using Visual Studio.Net command prompt by,
csc /r:system.runtime.remoting.dll /r:system.dll ServerApp.cs
A ServerApp.Exe will be generated in the Class folder.
Run the ServerApp.Exe will give below message on the console
Server ON at port number:8001
Please press enter to stop the server.
In order to check whether the HTTP channel is binded to the port, type http://localhost:8001/Service?WSDL in the browser.You should see a XML file describing the Service class.
Please note before running above URL on the browser your server (ServerApp.Exe should be running) should be ON.
Creating Proxy and the Client application on Machine 2
SoapSuds.exe is a utility which can be used for creating a proxy dll.
Type below command on Visual studio.Net command prompt.
soapsuds -url:http://<>:8001/Service?WSDL -oa:Server.dll
This will generates a proxy dll by name Server.dll. This will be used to access remote object.
Client Code:
using System;using System.Runtime.Remoting.Channels; //To support and handle Channel and channel sinksusing System.Runtime.Remoting;using System.Runtime.Remoting.Channels.Http; //For HTTP channelusing System.IO;using ServerApp;namespace RemotingApp{public class ClientApp{public ClientApp(){}public static void Main (string[] args) {HttpChannel channel = new HttpChannel (8002); //Create a new channelChannelServices.RegisterChannel (channel); //Register the channel//Create Service class objectService svc = (Service) Activator.GetObject (typeof (Service),"http://:8001/Service"); //Localhost can be replaced by //Pass Messagesvc.WriteMessage (10,20); }}}
Save the above file as ClientApp.cs. Create an executable by using Visual Studio.Net command prompt by,
csc /r:system.runtime.remoting.dll /r:system.dll ClientrApp.cs
A ClientApp.Exe will be generated in the Class folder. Run ClientApp.Exe , we can see the result on Running ServerApp.EXE command prompt.
In the same way we can implement it for TCP channel also.
---- Prabhakar Thallapalli

Multi Threading

Multithreading in .NET
Introduction
Asynchronous processing and background processing was always a must for serious programs serving complex user needs. The Windows NT platform offers a great way to accomplish this, but the implementation was sometimes tedious and always labor intensive. It is the reason why I first studied multithreading options offered by the .NET framework.
This article shows three different ways of creating (and using) threads, without communication and synchronization between them.
Before you start writing multithreaded programs, bear in mind some guidelines (from MSDN – Threading design guidelines):
Avoid providing static methods that mutate static state
Design for server environment
Instances do not need to be thread safe
Static states must be thread safe
Simple threading
Let’s first try the simplest way to create a new thread. The starting point for such a thread is void method with no parameters. Thread creation is done in two steps:
Create a delegate object, initialized with our method
Use this object as an initialization parameter when creating a new Thread object.
When our Thread object is created, call the Start method and background processing will commence.
public class MainClass{
public void threadMethod(){
...
}
public static void Main(){
...
ThreadStart entry = new ThreadStart(threadMethod ) ;
Thread thread1 = new Thread( entry ) ;
thread1.Start() ;
...
}
}
This sample hides the fact that using C# we do not have a global function, and usually you will start the thread on static class method.
public class Tester{
public static void Test(){
...
}
}
public class MainClass{
public static void Main()
...
ThreadStart entry = new ThreadStart( Tester.Test ) ;
Thread thread1 = new Thread( entry ) ;
thread1.Start() ;
...
}
}
Now we came to the first beautiful part of the .NET framework. We can start threads on class instances and create real living objects.
public class Tester{
public void Test(){
...
}
}
public class MainClass{
public static void Main()
...
Tester testObject = new Tester() ;
ThreadStart entry = new ThreadStart( testObject.Test ) ;
Thread thread1 = new Thread( entry ) ;
thread1.Start() ;
...
}
}
Timer threads
A common use of threads is for all kinds of periodical updates. Under Win32 we have two different ways: window timers and time limited waiting for events. .NET offers three different ways:
Windows timers with the System.WinForms.Timer class
Periodical delegate calling with System.Threading.Timer class (works on W2K only)
Exact timing with the System.Timers.Timer class
For inexact timing we use the window timer. Events raised from the window timer go through the message pump (together with all mouse events and UI update messages) so they are never exact. The simplest way for creating a WinForms.Timer is by adding a Timer control onto a form and creating an event handler using the control's properties. We use the Interval property for setting the number of milliseconds between timer ticks and the Start method to start ticking and Stop to stop ticking. Be careful with stopping, because stopped timers are disabled and are subject to garbage collection. That means that stopped timers can not be started again.
The System.Threading.Timer class is a new waiting thread in the thread pool that periodically calls supplied delegates. Currently it works on Windows 2000 only. Documentation for this class is not finished yet (beta 1). To use it you must perform several steps:
Create state object which will carry information to the delegate
Create TimerCallback delegate with a method to be called. You can use static or instance methods.
Create a Timer object with time to wait before first call and periods between successive calls (as names of this two parameters suggests, first parameter should be lifetime of this timer object, but it just don’t work that way)
Change the Timer object settings with the Change method (same remark on parameters apply)
Kill the Timer object with the Dispose method
If we put this in code we get:
Collapse
using System;
using System.Threading;

// class for storing current state
public class StateObj{
...
}

// class that will work on timer request
public class TimerClass{
public void TimerKick( object state ){
StateObj param = (StateObj)state ;
// do some work with param
}
}

// usage block
{
...
// prepare state object
StateObj state = new StateObj() ;
// prepare testing object – not necessary when cb is static
TimerClass testObj = new TimerClass() ;
// prepare callback delegate – careful on static methods
TimerCallback tcb = new TimerCallback( obj.TimerKick ) ;
// make timer
long waitTime = 2000 ; // wait before first tick in ms
long periodTime = 500 ; // timer period
Timer kicker = new Timer( tcb, state, waitTime, periodTime ) ;
// do some work
...
kicker.Change( waitTime, periodTime ) ;
// do some more work
...
kicker.Dispose() ;
...
}
For waitTime and periodTime you can use TimeSpan types if it makes more sense. In the supplied sample you can see that the same state object is used on both timers. When you run the sample the state values printed are not consecutive. I left it like this to show how important synchronization is in a multithread environment.
The final timing options come from the System.Timers.Timer class. It represents server-based timer ticks for maximum accuracy. Ticks are generated outside of our process and can be used for watch-dog control. In the sameSystem.Timers namespace you can find the Schedule class which gives you the ability to schedule timer events fired at longer time intervals.
System.Timers.Timer class is the most complete solution for all time fired events. It gives you the most precise control and timing and is surprisingly simple to use.
Create the Timer object. You can a use constructor with interval setting.
Add your event handler (delegate) to the Tick event
Set the Interval property to the desired number of milliseconds (default value is 100 ms)
Set the AutoReset property to false if you want the event to be raised only once (default is true – repetitive raising)
Start the ticking with a call to the Start() method, or by setting Enabled property to true.
Stop the ticking with call to the Stop() method or by setting the Enabled property to false.
using System.Timers ;

void TickHandler( object sender, EventArgs e ){
// do some work
}

// usage block
{
...
// create timer
Timer kicker = new Timer() ;
kicker.Interval = 1000 ;
kicker.AutoReset = false ;

// add handler
kicker.Tick += new EventHandler( TickHandler ) ;

// start timer
kicker.Start() ;

// change interval
kicker.Interval = 2000 ;

// stop timer
kicker.Stop() ;

// you can start and stop timer againg
kicker.Start() ;
kicker.Stop() ;
...
}
I should mention a few things about using the Timers.Timer class:
In VS Beta 1 you must add a reference to System.Timers namespace by hand.
Whenever you use the Timers namespace together with System.WinForms or System.Threading, you should reference the Timer classes with the full name to avoid ambiguity.
Be careful when using Timers.Timer objects. You may find them a lot faster than the old windows timers approach (think why). Do not forget synchronize data access.

Thread pooling
The idea for making a pool of threads on the .NET framework level comes from the fact that most threads in multithreaded programs spend most of the time waiting for something to happen. It means that thread entry functions contain endless loops which calls real working functions. By using the ThreadPool type object preparing working functions is simpler and for bonus we get better resource usage.
There are two important facts relating to ThreadPool object.
There is only one ThreadPool type object per process
There is only one working thread per thread pool object
The most useful use of a ThreadPool object is to add a new thread with a triggering event to the thread pool. i.e.. "when this event happens do this". For using ThreadPool this way you must perform following steps:
Create event
Create a delegate of type WaitOrTimerCallback
Create an object which will carry status information to the delegate.
Add all to thread pool
Set event
In C#:
// status information object
public class StatusObject{
// some information
}

// thread entry function
public void someFunc( object obj, bool signaled ){
// do some clever work
}

// usage block
{
...
// create needed objects
AutoResetEvent myEvent = new AutoResetEvent( false ) ;
WaitOrTimerCallback myThreadMethod = new WairOrTimerCallback( someFunc ) ;
StatusObject statusObject = new StatusObject() ;

// decide how thread will perform
int timeout = 10000 ; // timeout in ms
bool repetable = true ; // timer will be reset after event fired or timeout

// add to thread pool
ThreadPool.RegisterWaitForSingleObject( myEvent, myThreadMethod,
statusObject, timeout, repetable ) ;
...
// raise event and start thread
myEvent.Set() ;
...
}
A less common use of a thread pool will be (or at least should be, be aware of misuse) adding threads to be executed when the processor is free. You could think of this kind of usage as "OK, I have this to do, so do it whenever you have time". Very democratic way of handling background processing which can stop your program quickly. Remember that inside the thread pool you have only one thread working (per processor).
Using thread pool this way is even simpler:
Create a delegate of type WaitCallback
Create an object for status information, if you need it
Add to thread pool
// status information object
public class StatusObject{
// some information
}

// thread entry function
public void someFunc( object obj, bool signaled ){
// do some clever work
}

// usage block
{
...
// create needed objects
WaitCallback myThreadMethod = new WairOrTimerCallback( someFunc ) ;
StatusObject statusObject = new StatusObject() ;

// add to thread pool
ThreadPool.QueueUserWorkItem( myThreadMethod, statusObject ) ;
...
}
Some notes on thread pool:
Don’t use a thread pool for threads that perform long calculations. You only have one thread per processor actually working.
System.Thread.Timer type objects are one thread inside thread pool
You have only one thread pool per process
Conclusion
This article shows the way I used to find out secrets of .NET multithreading. When you try using this, be careful on thread synchronization. This is also subject of my next article, where I will show all different ways of synchronization that .NET offers.
For more information read articles in MSDN library:
.NET framework design guidelines
Threading design guidelines
Asynchronous execution
--------- Prabhakar Thallapalli

Generics in .Net 2.0

Generics
Generics are simply placeholders for actual types. Generics are defined with left and right brackets: In other words Generics allow you to define type-safe data structures, without committing to actual data types. .Net 2.0 provides number of generic collection classes for lists, stacks, queues, dictionaries.Generics Benefits:
Generics in .NET let you reuse code and the effort you put into implementing it. The types and internal data can change without causing code bloat, regardless of whether you are using value or reference types. You can develop, test, and deploy your code once, reuse it with any type, including future types, all with full compiler support and type safety. Because the generic code does not force the boxing and unboxing of value types, or the down casting of reference types, performance is greatly improved. With value types there is typically a 200 percent performance gain, and with reference types you can expect up to a 100 percent performance gain in accessing the type (of course, the application as a whole may or may not experience any performance improvements). The source code available with this article includes a micro-benchmark application, which executes a stack in a tight loop. The application lets you experiment with value and reference types on an Object-based stack and a generic stack, as well as changing the number of loop iterations to see the effect generics have on performance.
Let us create console application to have actual understanding.

In visual studio 2005 create new project >>Console Application Name it as "GenericsLists".

We will add class called as "Customer" to this console application as below:

public class Customer
{
private int custId;
public Customer(int Id)
{
this.custId = Id;
}
public override string ToString()
{
return custId.ToString();
}
}

With any of the console application we will have something called as "Program.cs"
Which will be some thing like this:

public class Program
{
static void Main()
{
//Type safe list (of Customer objects)
List custList = new List();
//Type safe list (of integers)
List intList = new List();
//Populate the Lists
for (int i = 0; i < 5; i++)
{
custList.Add(new Customer(i + 100));
intList.Add(i * 5);
}
//Integer list
foreach (int i in intList)
{
Console.Write("{0} ", i.ToString());
}
Console.WriteLine("\n");
//Print the Customer List
foreach (Customer Customer in custList)
{
Console.Write("{0} ", Customer.ToString());
}
Console.WriteLine("\n");
}
}

The Customer class contains a single private field (custId), a constructor, and an override of ToString to return the custId field as a string.

First you create an instance of List that will hold Customer objects. The type of custList is "List of customer Objects" and is declared as:

List custList = new List();

The definition List, the T is a placeholder for the actual type you'll place in that list.

if you try to add an integer to the list of Customer ie. custList.Add (i * 5);
In this case you will get two erros as:

The best overloaded method match for 'System.Collections.Generic.List.Add(ListCollection.Customer)' has some invalid arguments.

Argument '1': cannot convert from 'int' to 'ListCollection.Customer'.

Here it is not possible to implicit conversion of int to collection of Customer object or subtype one type implicit conversion to another type is not legal.

You can store types in a type sage collection. Thus collection of customer will hold "Sales" object if Sales derived from Customer.
Prabhakar Thallapalli.