By Dmitry Belikov

Channels

GTCP Channel

• Bi-directional link via single socket opened from the client.
• Client automatically re-establishes a connection broken due to network reasons. No messages are lost.
• Provides 5 events: connection established, connection accepted, connection closed, connection broken and connection restored.
• Detailed log capabilities including traffic being transferred.
• Automatic ping for checking the TCP connection.
• 100% .NET Remoting compatible, so you can attach custom sinks, formatters, etc.
• As an experimental feature, it supports opening multiple connections.

GHTTP Channel

• Bidirectional link.
• Sends several messages in the same HTTP request. It significantly helps when you send large number of small packets.
• Automatically reestablishes GHTTP connection.
• Automatically recognizes whether server has been restarted and fires connection closed event.
• GHTTP server channel works only inside IIS. GHTTP client channel does not have such limitations.
• Provides 3 events: connection established, connection accepted and connection closed.
• 100% .NET Remoting compatible, so you can attach custom sinks, formatters, etc.

Shared Memory Channel

• Bidirectional link.
• About 10-20% faster than GTCP via localhost.
• Provides 3 events: connection established, connection accepted and connection closed.
• 100% .NET Remoting compatible, so you can attach custom sinks, formatters, etc.

GUDP Channel

• Bidirectional link via single socket.
• Supports IP multicasting.
• Provides 3 events: socket exception, unregistered broadcast receiver requested and new remote host registered.
• Detailed log capabilities including traffic being transferred.
• Automatic ping for checking connection.
• 100% .NET Remoting compatible, so you can attach custom sinks, formatters, etc.

Broadcast Engine

• Broadcast Dispatcher manages list of MBR object supporting appropriate interface.
• Broadcast Dispatcher provides transparent proxy. When you call a method on it, dispatcher automatically broadcasts this message to each MBR receiver. Then it gathers responses from all the receivers and answers results. You always will get returned results and get to know failed receivers (with error messages).
• Supports local appdomain MBR receivers, remote MBR receivers that reachable only via usual channels (GTCP, GHTTP, Shared memory) and remote MBR receivers that accessible via true multicast channel.
• By default all receivers receive results via usual channels (simulation mode). Broadcast Engine automatically detects whether a receiver is accesible via true multicast channel and switch off the simulation mode for such receivers.
• IP multicast is based on connectionless datagram messages. Broadcast engine guarantees that the message will be re-sent via usual channel (GTCP, GHTTP or Shared memory) if a receiver didn’t receive it via true multicast channel for the specified timeout.
• All calls are made concurrently.
• Supports recipient filtering mechanism.

Compression, Encryption and SSPI Suport

Genuine Channels provide viable possibilities in invocation management. You can force such features as compression, encryption, impersonation, delegation, executing in the separate thread and so on in specific execution context.

Client Session

You can save client-related data into Client Session provided during each invocation and Genuine Channels event. If you need to mark some data with the client unique identifier, use can use remote host URI.

Queuing

Each connection within specific channel has a queue of messages being sent. All Genuine Channels define customizable constraints for their queues. It greatly helps to force reconnection if current connection is too slow or server is overloaded.

Event subsystem

Each channel supports various events. You can attach to either the specific channel or global event container that duplicates events from all channels.

Detailed Log

All connection processors (GTCP, GHTTP, Shared Memory and IP Multicast) write down all important events to the log file. So you will be able to analyze client or server activities. Log contains more detailed information then you can obtain via event subsystem.

Centralized Error Messages

Each exception has unique identifier which greatly simplifies centralizing error processing or translating error messages to any language. All error messages are located at one file, so you can easily translate them to any language.