Channel Frequently Asked Questions

Does the Remoting SDK support interaction between an application and a DLL?

No, but there is an optimized channel, based on the WM_COPYDATA message, for local inter-process messaging, which is faster than any TCP/IP implementation and less demanding in terms of resources. DLL's can be handled, too.

How can I avoid Unable to connect to remote server exception when SuperHttpChannel-based client is closed?

Check your Delphi settings and switch off LanguageExceptions.ShowOnLanguageExceptions setting or add EROException to Ignore Exception types list. You can also just ignore this exception.

How can I authenticate via WinInet Http client channel on a proxy server?

To set user name and user password for proxy settings:

var TestWinInetChannel = new WinInetHttpClientChannel();
(TestWinInetChannel as IHttpRequest).UsesAuthentication = true;
(TestWinInetChannel as IHttpRequest).AuthUsername = "UserName";
(TestWinInetChannel as IHttpRequest).AuthPassword = "UserPassword";

How can I configure IpHttpClientChannel or IpSuperHttpClientChannel client channels to connect through Http proxy (.NET)?

If you need to establish connection to the Remoting SDK server through Http proxy you need to set the proxy settings of the client channel:

IpHttpClientChannel clientChannel = new IpHttpClientChannel();
// .. other channel setup

// Proxy server address and port
clientChannel.ProxySettings.ProxyHost = "192.168.1.2";
clientChannel.ProxySettings.ProxyPort = 8080;

// Proxy server authentication (optional)
clientChannel.ProxySettings.UserName = "User";
clientChannel.ProxySettings.Password = "pass";

clientChannel.ProxySettings.UseProxy = true;

Note that if the ProxySettings.UseProxy property is set to false then client channel ignores all other proxy settings like hostname and port and tries to establish a direct connection to the server.

Both IpHttpClientChannel and IpSuperHttpClientChannel client channels also support secure https connections through Http proxy via SSL Tonneling.

How can I enable IPv6 Bindings for Indy-based server channels?

To enable IPv6 Bindings for Indy-based server channels, you have to add IPv6 binding into the Bindings option in the IndyServer:

How can I enable SSL for IpHttpServerChannel?

SSL in IpHttpServerChannel can be enables using following code:

//private RemObjects.SDK.Server.IpHttpServerChannel serverChannel;
this.serverChannel.HttpServer.SslOptions.Certificate =
  new System.Security.Cryptography.X509Certificates.X509Certificate2(@"c:\certificate_file.pfx", "password");
this.serverChannel.HttpServer.SslOptions.Enabled = true;

How can I enable SSL for HttpSysServerChannel or HttpSysSuperHttpServerChannel server channel (.NET)?

Note: Actions described below require adminstrator access rights.

  • Enable SSL support in the Server Channel's Bindings by setting its UseSSl property to true:
this.serverChannel.Bindings[0].UseSSL = true;
  • Configure the server host to use a SSL certificate. Usual approach is to use the httpcfg utility. Please refer to its documentation for more details.
    • Generate and install self signed Certificate

This can be done using the makecert tool or SSL Diagnostics Tool (available at Microsoft Downloads site)

Note: By default newly created certificates will expire in 2 weeks. Please obtain real (ie not self-generated SSL certificates for longer expiration period).

  • Configure host to use the certificate generated at step 2.1.

Now it is needed to associate the certificate just created with the port and IP address (or hostname) that the Server Channel is listening to.

This can be done via httpcfg.exe utility (8099 here is the port used by the HttpSys channel):

httpcfg set ssl /i 0.0.0.0:8099 /h 17332d70be26c02944f4b2089d5818a7d61e0c90

This command should complete with message 

HttpSetServiceConfiguration completed with 0.

17332d70be26c02944f4b2089d5818a7d61e0c90 here is Thumbprint hash of SSL certificate created on step 1. This thumbprint can be found via MMC Certificates snap-in. To open it issue MMC in command line, open File -> Add/Remove Snap-in menu item and add Certificates snap-in. It should use Computer account for local computer. Certificate can be found in Personal / Certificates folder

Double check the SSL bindings for this computer:

Issue

httpcfg query ssl

It should return

     IP                      : 0.0.0.0:8099
     Hash                    : 17332d70be26c02944f4b2 89d5818a7d61e c90
     Guid                    : {00000000-0000-0000-0000-000000000000}
     CertStoreName           : (null)
     CertCheckMode           : 0
     RevocationFreshnessTime : 0
     UrlRetrievalTimeout     : 0
     SslCtlIdentifier        : (null)
     SslCtlStoreName         : (null)
     Flags                   : 0

Now the server can be accessed via SSL-protected connection at URL like https://hostname:8099/bin

How can I handle handle enormous number of events from the Server in a Remoting SDK Client .NET application?

In general SuperHttp and SuperTcp client channels aren't configured to receive many events (more than 10-15) at one time by default. To handle events properly you need to do the following configuration steps:

  • In Visual Studio right-click on designer toolbox and register the ThreadPool component from RemObjects.SDK.dll
  • Drop it on your form from toolbox. Change its properties as follows:
    • MaxThread -- 100 (The maximal amount of threads that can be created within the ThreadPool class, default is 10).
    • MaxQueue -- 10000 (The maximal amount of events in queue for each thread, default is 50).
    • PoolThreads - 100 (Default is 5).
  • Set ClientChannel's property EventThreadPool property on this component.

Of course you can also create instance of the ThreadPool class and configure it at runtime.

Now your client allication will be able to handle large amount of events.

How can I send large amounts of data from client to the server?

For security reasons there are some restrictions on package size that can be sent over the network.

Channel side

Each server channel component has some properties to manage that.

Synchronous channels

All synchronous server channels like IpHttp, IpTcp, HttpSys and NamedPipes do have a Security Options property category. You can just turn off security by setting the EnforceSecurity property to False (True by default - meaning security is on). Obviously, we can recommend that approach only for testing/debugging purposes. You can leave security on, but increase the value for the MaxRequestSize property. By default it allows to handle packages up to 5 megabytes (5242880 bytes) in size.

Asynchronous channels

Async channels like IpSuperTcp and IpSuperHttp only have one property MaxPackageSize. By default, it allows to handle packages up to 1048576 bytes (1.0 Mb) in size.

Message side

The binary message component also has a MaxMessageSize and MaxDecomperssedMessageSize property that limits size of data that can be handled. You can increase it to a bigger value. All other messages don't have a restriction.

If you need to send a huge amount of data over the network, the best approach is to split the data into small chunks and send them separately and possibly in several threads. The Extended File Transfer sample shows how to download big files by chunks.

What is the difference between various super tcp channel timeouts?

There are four types of timeout to consider:

  • ConnectionWaitTimeout: The time request waits for the connection to become available before it fails (Default: 10000 msec).
  • AckWaitTimeout: The time the client waits for an ACK back from the server (i.e., the server received the package and is handling it; default: 10000 msec).
  • IdleTimeoutMinutes: When set to anything except 0, the client will disconnect after not being used for this length of time. This can be useful to reduce traffic, but it shouldn't be set when using events.
  • RequestTimeout: Time to wait after the ACK has been received; defaults to the maximum of 60000 msec.

When do event receivers require their own channel?

You always need a separate channel for the event receiver.

The important exception to this rule is the SuperChannel, which is multi-thread aware. It doesn't need or support a separate channel for multiple requests when receiving events from the server.

Which of the many channels available should I choose and why?

There is an article available that covers this question: Comparison of the Remoting SDK Channels.

Why does the TCP Super Channel use more threads than expected?

An average TCP Super Channel server has these threads:

  • Thread pool: With the maxthreadcount of 5, this will use a maximum of 5 threads which will stay in memory.
  • timeout timers: We use the System.Threading.Timer to handle timeouts. .NET creates one or more threads for this, depending on the number of timers.
  • IOCP: Windows handles the async IO threads. The algorithm is controlled by Windows, but we use IOCP for the listening and the reading/writing of data to the remote sockets.
  • GC: Garbage collection is something .NET handles, using a thread that sleeps most of the time.

As you can see, half of the threads for the classes we use are created by .NET, and not controlled by us.