Socket SEND()

[Kenneth Brody]

Quoting Nancy Palmquist (Fri, 07 Nov 2008 14:13:14 -0500):

> Thank you all for the recv() advice.  I was sending XML so I just   
> collected data until the final tag was received and all started  
> working.
>
> Now I notice that the send() side has similar issues, but I am not   
> sure how to test that the file was completely sent.
>
> Programming goes like this:
>
> status=send(accept_handle,ry{"")
>
> if status ne instr(ry{"[**","[**","1")-"1" then I know I did not send the
> correct number of bytes.  I have error trapping for this.  But it is  
>  not triggered.

You could put it into an uncast field, and check its length:

     Declare UncastField
     UncastField = ry { ""
     If: status ne len(UncastField)

> status=socketclose(accept_handle)
>
> BTW: using instr to figure out string length because dlen() causes CRASH on
> fields longer than "4***" on this version.

What version?  And does it crash, or simply max out at 4095?  This was a fix
several years ago in 5.0.12:

(All) #662

     DLEN() had an undocumented limit of 255 characters on the input
     string.  The input is now unlimited, and the output is limited
     to 4095.

Remember, the purpose of DLEN is to determine the display length of a value,
and there are only 2000 characters on the screen.

> I get a socket error -10054 at the recv() end of this which means   
> the socket was closed by the host before the data has completed its
> trip.

That shouldn't happen unless you try to continue reading after you read
the last thing sent.  I wonder if it may make more sense in your case to
use SENDLINE() and RECVLINE() instead?

> The value of status was correct, so I closed the socket.  However,   
> the data had not flowed back fully.  I added a SLEEP "1000" between
> the send() and the socketclose() and it started working.

Again, there's no guarantee that that pause will let the receiving end
"see" the last bytes sent before you close it, but it does make it more
likely in anything but connections with long propagation times.

> Is there a data related way to handle this?  I am worried that the   
> SLEEP "1000" might not be long enough and it is wasting time if it is
> too long.
>
> On the receive side, I could check the data to make sure it was all   
> there.  On the send() side if the number of bytes sent is not real,
> how can I tell how long to wait before closing the socket?
>
> I really appreciate any help, even if it does not relate to the   
> filepro sockets.
>   You were all very helpful last time.

-- 
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com