Adding a Progress Bar to a Web Service Client

[Chuck Hartman]

The client app that I am developing is calling a web service that may take a
long time to execute. I want to include a progress bar in my client that is
attempts to show the relative time left to complete the current task. I am
using the MSDN article by Matt Powell entitled "Adding a Progress Bar to
Your Web Service Client Application" as a basis for my solution.

The web services extension will keep track of how much of a given transfer
is complete. This assumes that the TransferSize variable in Matt's example
is known in advance. Matt seems to use the value, but never seems to set
its value. My question is, how to determine in advance what the total size
of the response to be transferred will be? Also, can this same technique be
used to show the progress of a large request as well? Thanks.

Chuck Hartman

 

[Steven Cheng[MSFT]]

Hi Chuck,

Welcome to MSDN newsgroup.
I think the sample program in the tech article you mentioned is actually a
clientside progressbar which didn't
consider the executing time consumed at the serverside. As we can see in
the SOAPExtension's
ProcessMessage method:

All the progressBar's updating code in in the
BeforeDeserialize stage,
================
case SoapMessageStage.BeforeDeserialize:
// This is where we stream through the data
SoapClientMessage clientMessage
= (SoapClientMessage)message;
if (clientMessage.Client is ProgressClient)
{
ProgressClient proxy


..................
==================

this means at that time, all the Response Data has been arrived at the
clientside.

And the "TransferSize" property, my assumption is that it is assigned as
the

"oldStream"'s Length, as we can see in the later While { } block, it read
"m_readSize" each step, so the
TransferSize should be Stream.Length/100. Do you think so?

====================
....................
m_readSize = proxy.TransferSize / 100;
m_progressDelegate = proxy.ProgressDelegate;
}
while (true)
{
try
{
int bytesRead
= m_oldStream.Read(m_bufferIn,
0,
m_readSize);
if (bytesRead == 0)
..................
=========================

Thanks & Regards,


Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Chuck Hartman]

Steven,

I know that Matt's example is not monitoring the server side execution time.
In my case, the server side execution time is small compared to the elapsed
time it will take to transfer the relatevely large response stream across
the wire. But in order for the progress bar to truely track progress of the
response across the wire, it would seem that you would need to know the
total size of the response before it starts across the wire. Must the
response stream size be known in advance?

Matt's example says that it is capturing the response AS it is being
received not AFTER it has been received. If all of the response data has
already arrived at the client, then the example is not accomplishing what it
seems to claim. Am I missing something? Thanks.

Chuck Hartman

 

[Steven Cheng[MSFT]]

Hi Chuck,

AS Matt has mentioned in that article, the clientside is very limited, what
we can do is to capture the response as it is being returned as close to
the wire as possible. But due to the webservice's distributed underlying
mechanism, we can not know how much datas we've finally recieved in
advance. Also, as in the following section:

=============================
We are interested in the response. We want to monitor the data as it comes
across the network, instead of after it has already been buffered and
deserialized. We will therefore be doing the majority of our work in the
BeforeDeserialize stage.

==============================
'
that means our progressbar displaying occurs when the clientside's runtime
is deserializing the message, and the message's data must has arrived the
clientside. So it mainly displaying the progress that the raw Message data
being deserialized into the WebService's response object rather than the
progress of the datas transfering on wire.

Thanks.

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)