Socket SEND()

[Nancy Palmquist]

Kenneth Brody wrote:
> 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.

It is version 5.0.14 and the results will cause a Seg violation dump kind of 
error.  Nothing that filePro traps, it just dumps you out.

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

I could never get len() to give me the correct value, because it reported the 
length assigned to the variable, not the length of the data.  Assigning stuff to 
uncast fields just to get the length seemed silly.  DLEN(variable{"") will give 
you the number of characters not the length of variable as it is defined.  Maybe 
I just understood the intent different.  Why bound it to 2000 at all?
> 
>> 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.

You are exactly right, this is my worry.  The length of time is arbitrary and I 
have no way to tell from the send() side that the transaction is complete before 
I do the socketclose().  The number of bytes sent is not telling me that they 
are really sent.

How would sendline() nad recvline() make any difference?  The length of the data 
sent will vary, should I send it in blocks until it is all sent.  I think that 
would have the same issue.  If I can not tell on the send() side if all the 
bytes were received at the other end, how can I be sure it will work if I use 
sendline() that requires I send a length and how do I know it got sent?

Why wouldn't the socketclose() wait until the transaction is complete to happen?

I always expect one command to complete before the next command is executed and 
for filePro to handle this kind of thing.  I find it very difficult to try to 
program with this kind of silliness.

If I wanted to handle all the communications myself, I would not use filePro.  I 
think filePro should handle the I/O correctly without my help, just like it does 
when I write or read a file, it handles locks, updates indexes and generally 
makes it happen correctly.
> 
>> 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.
> 

Nancy

-- 
Nancy Palmquist 		MOS & filePro Training Available
Virtual Software Systems	Web Based Training and Consulting	
PHONE: (412) 835-9417		   Web site:  http://www.vss3.com