Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 8 of 8 total |
OT: Problems when returning progress to a client |
Thu, Jul 10 2008 4:37 PM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 AM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 PM | Permanent 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 PM | Permanent 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 PM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 |
This web page was last updated on Wednesday, April 24, 2024 at 11:07 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |