The application is a simple Chat server and Client, which is conversion of Java RMI chat server and client. The Java client was a Applet and present application client in WinForm.
You can find the original Java code from [Troy Downing firstname.lastname@example.org http://www.webcal.com/downing/ February 1997]
Serialization : Serialization is the process of converting a graph of objects, into a linear sequence of bytes. That sequence of bytes can be sent elsewhere (for example, to a remote computer) and Deserialized, thereby making a clone in that remote memory of the original graph of objects. Serialization is necessary in this application to have the state of the Remote Object on the client and server at the same time.
Remoting : Microsoft .NET Remoting provides a rich and extensible framework for objects living in different AppDomains, in different processes, and in different machines to communicate with each other seamlessly. .NET Remoting offers a very powerful yet simple programming model and runtime support for making these interactions transparent.
.NET Remoting Objects
There are three types of objects that can be configured to serve as .NET remote objects. You can choose the type of object depending on the requirement of your application. This section explains these objects in detail.
"Single Call" objects service one and only one request coming in. Single call objects are useful in scenarios where the objects are required to do a finite amount of work and usually not required to store state information. Single Call objects can be configured in a load-balanced fashion. Single Call Objects cannot hold state information between method calls.
"Singleton" Objects are those objects that service multiple clients and hence share data by storing state between client invocations. They are useful in cases where data needs to be explicitly shared between clients and also where the overhead of creating and maintaining objects is substantial.
In the sample we have to use singleton because of the nature of the application.
Client Activated Objects (CAO) are server side objects that are activated on request from the client. This way of activating server objects is very similar to the classic COM coclass activation. When the client requests for a server object using "new" operator, an activation request message is sent to the remote application. The server then creates an instance of the requested class and returns an ObjRef back to the client application that invoked it. A proxy is then created on the client side using the ObjRef. The client's method calls will be executed on the proxy. Client Activated Objects can store state information between method calls for its specific client and not across different client objects. Each invocation of "new" returns a proxy to an independent instance of the server type.
Passing Objects Using .NET Remoting
In .NET Remoting, objects can be passed from one application to another in the following ways:
- As parameters in method calls
Example: public int myRemoteMethod (MyRemoteObject myObj)
- Return Value of method calls
Example: public MyRemoteObject myRemoteMethod(String myString)
- Values resulting from property or field access of a .NET component
For objects that are Marshal By Value (MBV), a complete copy of the object is made when the object is passed from one application to another.
For objects that are Marshal By Reference (MBR), a reference to the object is made when passed from one application to another. When the object reference (ObjRef) arrives in the remote application, it is turned into a "proxy" back to the original object.
Hosting .NET Remoting Objects
.NET Remoting objects can be hosted in:
- Managed Executable. .NET Remoting objects can be hosted in any regular .NET EXE or a managed Service.
- IIS. Remoting objects can be hosted in Internet Information Server (IIS).
- .NET Component Services. .NET Remoting objects can be hosted in the .NET component services Infrastructure to take advantage of the various COM+ services like Transactions, JIT, Object pooling, etc.
Channel Services (System.Runtime.Remoting.Channels)
The .NET framework supplies the HTTP, TCP and SMTP channels but third parties can write and plug in their own channels. The HTTP and SMTP channels use SOAP by default to communicate whereas the TCP channel uses Binary payload by default.
Present Application uses TCP channel to communicate.
About the sample
Server is a console application and client is Win Form. This application uses Remoting Namespace of .NET to transfer the Server Object on wire and gets created on the Client. Remoting can be done in .NET by many means (channels), TCP channel is used in the present sample. You can use HTTP channel or SOAP to do this too.
Good luck and Enjoy C#.