Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 8 of 8 total
Thread OT: Problems when returning progress to a client
Thu, Jul 10 2008 4:37 PMPermanent Link

"Eduardo [HPro]"
Hi everyone

I am going to try to explain my problem.

1) C/S environment
2) Client send a string with function name to be processed by the server and
wait (until 10 minutes).
3) Server receive the call from client and load a DLL into a new thread
passing ClientSocket to the DLL
4) Inside DLL I use ClientSocket to send progress to the client application

The step 4 is the problematic because if I don´t send any information back
(about progress) and just the results (as designed) the solution works so
good (it is already running in a lot of my customers). When I send progress
back to the client, the information sent is stacked and the client receive
"Wait, processing 1%Wait processing 2%Wait processing 3%".

I really apreciate any comments.

Eduardo

Thu, Jul 10 2008 6:01 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Eduardo,

<< The step 4 is the problematic because if I don´t send any information
back (about progress) and just the results (as designed) the solution works
so good (it is already running in a lot of my customers). When I send
progress back to the client, the information sent is stacked and the client
receive "Wait, processing 1%Wait processing 2%Wait processing 3%". >>

You're going to have to develop an envelope for the messages being sent so
that the client knows how to parse them in the incoming Winsock stream of
data.  The envelope can be as simple as a single integer representing the
message type followed by a length indicator and, finally, the actual data.

--
Tim Young
Elevate Software
www.elevatesoft.com

Fri, Jul 11 2008 10:52 AMPermanent Link

"Eduardo [HPro]"
Tim

> You're going to have to develop an envelope for the messages being sent so
> that the client knows how to parse them in the incoming Winsock stream of
> data.  The envelope can be as simple as a single integer representing the
> message type followed by a length indicator and, finally, the actual data.

I really understand what you are saying and it is almost done but...

I have created an envelope with format <<PERCENTDONE999>> where 999 is the
percent number. I am using 8k buffer and have realized TCP/IP sometimes
break the format and send for example <<PERCEN and another message it
"complete" with TDONE999>> but I don´t know why sometimes one package ends
with <<PER and the following package starts with DONE999>> and CENT is
missing. I am testing with a simple loop at server side from 1 to 100 and
because the size of buffer it works everytime but I have tried to add more
emotion and put a loop from 1 to 1000, this is enought to show the described
problem.

Could you drive me to solve this problem ?

Eduardo

Fri, Jul 11 2008 12:18 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Eduardo,

<< I have created an envelope with format <<PERCENTDONE999>> where 999 is
the percent number. I am using 8k buffer and have realized TCP/IP sometimes
break the format and send for example <<PERCEN and another message it
"complete" with TDONE999>> but I don´t know why sometimes one package ends
with <<PER and the following package starts with DONE999>> and CENT is
missing. I am testing with a simple loop at server side from 1 to 100 and
because the size of buffer it works everytime but I have tried to add more
emotion and put a loop from 1 to 1000, this is enought to show the described
problem. >>

You cannot rely on the incoming TCP/IP stream being in any particular size
chunks of data.  You simply have to loop on the Receive() until you know
that you've received all of the data that was indicated by the data length
indicator in the message envelope, appending each receive to the end of the
received data buffer.

--
Tim Young
Elevate Software
www.elevatesoft.com

Fri, Jul 11 2008 1:17 PMPermanent Link

"Eduardo [HPro]"
Tim

> You cannot rely on the incoming TCP/IP stream being in any particular size
> chunks of data.  You simply have to loop on the Receive() until you know
> that you've received all of the data that was indicated by the data length
> indicator in the message envelope, appending each receive to the end of
> the received data buffer.

I know that but my problem is that server sends "PERCENTDONE" and
client receives "PER" in one package and "DONE" in the next package and what
about "CENT" that is missing ?
I am not thinking in one specific buffer size, it really does not matter but
I expect "PER" in one package and "CENTDONE" in the next one.

Eduardo

Fri, Jul 11 2008 1:19 PMPermanent Link

"Eduardo [HPro]"
Tim

In the server side there is a following code (inside a DLL that is loaded by
a server thread) only for tests.

    for nI := 1 to 1000 do begin
       cRet := '<<PERCENTDONE'+format('%.3d',[nI])+'>>';
       while ClientSocket.SendBuf(cRet[1],Length(cRet)) = -1 do begin
          Sleep(50);
       end;
    end;

Eduardo

Fri, Jul 11 2008 3:07 PMPermanent Link

"Eduardo [HPro]"
Tim

I have found the problem. It was my fault (at client side).
I really apreciate your help. It works like I expect.

Eduardo

Fri, Jul 11 2008 5:28 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Eduardo,

<< I have found the problem. It was my fault (at client side). I really
apreciate your help. It works like I expect. >>

I'm glad you found the problem and things are working okay now.

--
Tim Young
Elevate Software
www.elevatesoft.com

Image