RO & DA transfer statistics (for HTTPSRO server)

I am interested in knowing how much data gets transferred over the internet for certain RO calls and for certain DA linq GetTable requests.

Here’s what I am missing

  1. Can I get the size in bytes of the RO HTTPS channel (upload or download) for a particular RO call.
    Some calls will transfer Bin2DataStreamer containing a DataTable. Iknow the size of the Binary data but I believe the IpSuperHttpClientChannel or BinMessage supports compression. I would like to collect the compressed size.
  2. Can I get the size in bytes of a DA call dataAdapter.GetTable RemoteTable when fully read.
    Note: I copy to a DABindingList

Hello

You need to temporarily switch to IpHttpClientChannel and to add there these event handlers:

            this.clientChannel.AfterReceiveStream += ClientChannel_AfterReceiveStream;
            this.clientChannel.BeforeSendStream += ClientChannel_BeforeSendStream;
...
        private void ClientChannel_BeforeSendStream(object sender, StreamEventArgs e)
        {
            System.Diagnostics.Debug.WriteLine($"Sent: {e.Stream.Length}");
        }

        private void ClientChannel_AfterReceiveStream(object sender, StreamEventArgs e)
        {
            System.Diagnostics.Debug.WriteLine($"Received: {e.Stream.Length}");
        }

Unfortunately these events won’t work for IpSuperHttpClientChannel, at least for now.

OK, thanks

  1. with temporarily you mean until an SDK is released which has these events for IpSuperHttpClientChannel , correct?

  2. In our speed tests IpHttpClientChannel performed as well as IpSuperHttpClientChannel. What disadvantage do we have if we (permanently) switch to IpHttpClientChannel.

  3. Do you have an answer for my second question? Can the DataTable size be returned starting from a RemoteLinqDataAdapter which performs GetTable and then ToDABindingList?
    I realize (assume) the stream data size can be collected via the underlying channel via your first solution.

Hello

Yes. However there is no ETA for this, at least for now. Such events should be added really carefully, to avoid possible performance and stability issues. Id of the registered issue is #19164

Main advantage (and at the same time a disadvantage) of Super- channels is that they maintain persistent connection between client and server apps. This gives faster response rates, especially when several requests are sent to the server in a batch.
Unfortunately on unstable connections Super channel might reconnect often or even lose the connection altogether.
Simple- channels establish connection to the server anew on every request (or on every request batch if KeepAlive option is enabled). This might result in some time delay on server call. At the same time the server app might be even restarted between calls - the client app won’t even notice that.

Also clients that use Super- channels receive Server-sent events immediately when they are raised. Events are pushed to the clients. Simple channels polls perform poll calls to load server events info.

Take a look at the last line:

            var dataModule = new DataModule();

            var query = from x in dataModule.DataAdapter.GetTable<Supplier>() select x;
            var data = query.ToList();
            Console.WriteLine("Count: " + data.Count);

            Console.WriteLine(((Binary)dataModule.DataAdapter.DataRequestCall.ResultParameter.Value).Length);

It shows the length of decompressed data stream received from the server.
Please note that this solution might eventually stop working, this data has to be cleaned up after the data request is finished, so eventually DataAdapter code will be updated to do that.

Could you describe why do you need this statistic? This will help us to decide where to put possible extension points to gather it in a more streamlined way.

Regards