The major goal for this release was to bring Eneter messaging functionality for devices such as PDA and factory controllers so that they can easily talk not only to each other but also to applications based on other platforms (e.g. .NET, Java and Android).
Many of these embedded devices are still running on Windows CE operating system that supports .NET Compact Framework which is the scaled down version of standalone .NET Framework.
So porting Eneter communication functionality for Compact Framework 2.0 and Compact Framework 3.5 enables these devices to communicate with applications based on following platforms:
- Java 6
- Android 2.1 (or later)
- .NET 3.5 and 4.0
- Windows Phone 7 and 7.1
- Silverlight 3, 4 and 5
- Mono 2.6.4
Here is the summary of supported features in Eneter for .NET Compact Framework:
ProtocolsEneter for .NET Compact Framework supports following protocols and transportation mechanisms:
- TCP - for communication between applications running on different machines.
- WebSockets - for communication between applications running on different machines. It provides bi-directional, full-duplex communication in environments which block non-standard Internet connections using a firewall.
- HTTP - for communication between applications running on different machines. It works in environments blocking non-standard Internet connections using a firewall.
- Thread Messaging - for communication between threads running in the same process.
Communicated messages can be serialized/deserialized with:
- XML Serializer - serialization to XML.
- GZip Serializer - for compressing big messages before sending across the network. (not available in Compact Framework 2.0)
Sending Receiving Messages
To implement the communication between applications, the framework provides functionality to send and receive messages. Communication can be one-way or request-response and messages can be:
- String Messages - for sending and receiving text messages.
- TypedMessages - for sending and receiving data structures of specified types.
It provides components that can be placed on the communication path to control the routing behavior.
- Broker - for publish-subscribe scenarios (publisher sends messages to the broker and the broker notifies all subscribers).
- Router - for re-routing messages to a different address.
- Dispatcher - for routing messages to all connected receivers (e.g. for a service listening to TCP and HTTP at the same time).
- Load Balancer - for distributing workload across multiple computers.
- Channel Wrapper/Unwrapper - for receiving multiple types of messages on one address (no need for if ... else ... statement in the user code)
The communication across the network is typically less reliable as a local call inside a process. The network connection can be interrupted or a receiving application can be temporarily unavailable. If your communication scenario requires overcome these issues, the framework provides:
- Monitoring of connection availability - for early detection of a disconnection.
- Buffered messaging and automatic reconnect - for overcoming short disconnections (e.g. in case of unstable network).