Communication system model
What is a communication framework? Generally a communication framework is an object delivery system. No more and no less. If this system implements RPC/RMI, another layer is built on the top of that. The object delivery system in turn consists of just two major sub layers:
1 Transport layer (physically delivers the stream of bytes to the destination)
2. Converter from the byte stream to the object (a serializer) And nothing else.
The rest can be hidden inside this ideal communication framework.
The late statement is true only for the systems that describe the objects in the same terms (same OS, same .NET framework)
Minimal (Optimal) communication system
Minimal communication system has just one method Send(Object). Does the programmer have to care how the object is converted to the byte stream, How it is managed by the threads, how queued, fragmented etc.? No, it is the communication framework job.
Why do we need the communication framework at all?
Really why, there are standard Remoting and Windows Communication Foundation. Apart from that a few open source and commercial frameworks are available.
Remoting
*Remoting is not implemented for the Compact Framework.
*Standard remoting is based on just synchronous communication model.
*It is unidirectional. The attempts to use call backs for the duplex communication do not work with the client behind proxy or NAT because Remoting opens a second connection for the events. Since the firewall is a standard network component, we may forget about bidirectional communication using remoting.
*Impossible to use Socks4/5 proxies with it.
Windows Communication Foundation (WCF)
*WCF is not implemented for Compact Framework (only 3.5 beta)
*The sender and the receiver are loosely coupled.
*WCF runs only on Windows
*Too complex to use.
*The WCF performance is far from perfect (generally due to the SOAP serialization)
*It does not have a generic serialization mechanism. Instead only semi manual Serialization is implemented.
Judge for yourself:
public class Person
{
public string FirstName;
public string LastName;
public int ID;
ArrayList alist = new ArrayList();
public ClassB _b;
}
|
In WCF the decoration of such a primitive object for serialization looks like:
[DataContract(Name = "Customer", Namespace = "http://www.contoso.com")]
class Person : IExtensibleDataObject
{
[DataMember()]
public string FirstName;
[DataMember]
public string LastName;
[DataMember()]
public int ID;
[DataMember()]
ArrayList alist = new ArrayList();
[DataMember()]
public ClassB _b;
private ExtensionDataObject extensionData_Value;
public ExtensionDataObject ExtensionData
{
get
{
return extensionData_Value;
}
set
{
extensionData_Value =value;
}
}
}
|
Does everybody like that? Apparently not. The web is full of blogs suggesting numerous "smart" solutions overcoming the restrictive nature of WCF. The limited WCF serialization is "successfully" worked around by using BinaryFormatter and then putting the byte array as a parameter. Is it the price paid for the interoperability? Microsoft apparently sacrificed versatility for interoperability simply by limiting the functionality. The logical extreme of such approach would be a return to the old good raw socket communication. Hence most of the WCF programs run on Windows, would it be more sensible having the generic serializer as a default and the rest as an option?
What makes the communication framework OS specific
The only thing that makes the system OS specific is the formatter (the serializer). It is the only component in the system that converts the stream to the object. The stream is always same. As the sculpture is made of stone (any stone) so the object is made of stream. In fact WCF has all these bits and pieces but the way the system is composed is far from perfect.
Total recall
.Net standard communication suffers from the same disease that Windows OS suffered 10 years ago. Core Windows API is same as it was 10 years, but the programming of Windows Form Application 10 years back was a serious ordeal. Why? Because the programmer had to provide all the parameters manually. In order to provide all the parameters, he needed to know all Windows internals and how to use them. In .Net environment all the defaults are set by the framework. We drag the controls from the toolbox and the rest is done automatically. If we need extra features, we can select them from the property grid or type them in the code.
In the real life we send the object (the letter or the parcel) to the recipient. Do we really care how the letter is delivered, what is the postman's name or the name of his pet dog? No, we don't. Usually we drop the letter in the postbox and the rest is done by default. If we want some extra features, like better security or delivery confirmation, we can get that as an extra. If the letter delivery looked like .NET communication (WCF in particular), the procedure of the letter delivery would have certainly been like that: we select from the catalog the number plate of the car that carries the letter, the name of the driver, the flight number, the type of the plane, envelope color, brand …. Most probably that would stop us from sending the letter at all.
DotNetRemotingPlus framework
This framework is free from the problems described above. It is extremely easy to use software. Only a few lines of the code make the advanced bidirectional communication system.
Features
Bidirectional communication on just one port open
Communication model : sync/async/remoting object based (not a string or special object)
Built for .Net full and Compact Frameworks
Outstanding performance (20 times faster than Webservices)
Accessibility for Clients behind NAT, Firewall or Proxy
Scalability (thousands of clients)
Supported protocols TCP, HTTP, UDP
TCP/HTTP Broadcasting mode + UDP multicast
Keeps the connection alive
Handles all threads internally
Built in and external Encryption
GPRS support(for PDAs, Smartphones)
Chunked File Transfer (with progress event) new
Chat componets (ChatServer/ChatClient) new
Lost Connection Autorecovery on PDA (reconnection on wake up)
Native DataSet and DataTable support (inc PDA and Smartphones)
Fully integrated with Visual Studio Toolbox
Support for Socks4/Socks5 proxies
100% Managed code
No deployment license fees
Optional Fast Serialization
Development tools [Serialization Studio, Proxy Studio]
The framework is fully intergrated with Visual Studio
Building the client or the server is just dragging the components from the toolbox to the form.
If the components are used with Services or Console application, only couple of lines will build the client (server).
The details how to program DotNetRemotingPlus can be found in the Programming manual
DotNetRemotingPlus and object serialization
The framework has a built in generic serializer, that is used with Compact Framework.
(Standard Compact framework does not implement binary serializer)
However if you want to use standard BinaryFormatter (only with full framework), the serializer can be switched by dropping BinSerializer.dll to the run directory.
This option will not work with Linux. BinaryFormatter on Linux is not compatible with BinaryFormatter on Windows. In this case built-in serializer has to be used.
Extreme performance and serialization
For the extreme performance (faster than standard binary serializer by 20 times) the utility application Serialization Studio can be used to generate super fast serializers.
These super fast serializers can be natively integrated with DotNetRemotingPlus
Behind Proxy or NAT
Since only one connection is open for both direction, the communication behind the NAT is not a problem any more.For the ultimate firewall transparency special components have been derived from DNR base classes. (NoFirewall tunnel, Peer-to-Peer, and Skyping)