|
Hi Jim,
Thanks for the reply. I'm glad you got it all figured out.
One thing I can suggest for the "fixed 8 bytes" issue is to simply add
the data as you receive it to a buffer... then once you have 8 bytes,
use that.
If you want the program to wait for the data, this could be accomplished
with a simple loop. Here's a similar piece of code from one of my
programs:
c eval wkOutLen = 0
c dou wkOutLen >= %size(wkOutBuf)
c eval wwRecvLen = %size(wkOutBuf) - wkOutLen
c eval p_RecvBuf = %addr(wkOutBuf) + wkOutLen
c eval wwRC = recv(peSock:p_RecvBuf:wwRecvLen:0)
c if wwRC < 1
c leave
c endif
c eval wkOutLen = wkOutLen + wwRC
c enddo
With that code, if wkOutBuf is 8 bytes long, it'll keep receiving data
until it fills it up...
On Wed, 15 May 2002, Jim W wrote:
>
> First of all, thanks again for your help. (Once again the list comes
> through!) I've been out of the office, and this is the first chance I've
> had to let you know what happened.
>
> <SNIP>
>
> I also note this:
>
> * ....Receive first 8 bytes of header length
> C Eval RC = Recv(I: SocketData@
> C : 8: 0)
> <SNIP>
>
> Also keep in mind that recv() will return whatever is in the receive
> buffer for the socket. It isn't necessarily 8 bytes long. It may be
> only part of the 8 bytes you need... you should be either using some sort
> of delimiter (usually CR/LF) to determine when a whole message has been
> received, or else you should be using a loop to get a fixed length of 8
> bytes... I hope you understand what I mean, as this is a bit too much
> to try to fully explain in this message...
>
>
> The reason I was looking at only 8 bytes is that every message being sent by
> the other end has an 8 byte message length header. I needed to get the
> length and then do a second receive for that length. If not I could get
> part of the following message in my receive and get everything out-of-wack.
> The messages we are receiving have no CR/LF type EOR delimiters.
>
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.