|
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.