First, let me say thanks for responding. My other responses are embedded
within your reply:
> > What is strange is that I can always get the "char data[]" structure
> > member, and sometimes I get meaningful data in a few of the shorts, but
> > never all of the structure's members at the same time.
>
> Do you consistently get the same problems on the FIRST record returned?
Yes.
>
> Anything after that is suspect, as you may be so far off-sequence that the
> rest are meaningless.
>
> What data do you actually get for the first record?
Depends on what formatting I use with the unpack, but I've been able to
get one of the shorts to contain an expected value. I kept the
description short and didn't include the fact that most of the server
responses are much less than the 4K buffer size. But in all cases I seem
to get the char data that appears in the 4K buffer.
>
> Also, call me crazy, but, like, aren't you THROWING AWAY most of your
> buffer?...
Well, the code snippet is from a proof of concept. I could easily write
a C-lang client, call it from a PHP exec() call, etc, etc... BUT, that
doesn't help us determine if we can use PHP for this purpose. So, at
this point I don't really care, but I see why you would question my
logic.
>
> Or, in this case, reading only HALF (roughly) of a record at a time.
>
> You read 2048 bytes.
> You trim it (probably a bad idea)...
This was robbed from a prior example on www.php.net, but I can remove it
to see if it helps.
> You try to unpack all 2048 bytes as if it was a single record.
> You ignore anything after that in the buffer, and loop to get 2048 more
> bytes.
>
> But each record you receive is supposedly:
> short+short+short+short+REPLY_MSG_SIZE+1 bytes long.
> 2 + 2 + 2 + 2 + 4000 + 1
> 4009
> bytes for a single record.
>
> I think you want something more like this:
>
> $socket_buffer = '';
> $parse_buffer = '';
> $format = "@0/sval0/@1/sval1/@2/sval2/@3/sval3/@4/sval4/@5/sval5/@6/C*";
> while ($socket_buffer = socket_read($msgsock, 2048, PHP_BINARY_READ)){
> if (false == $little_buffer){
> //Your $ret was not defined...
> echo "Failed socket read ", socket_strerror(socket_last_error($msgsock));
> //If you are gonna keep going, clear the socket error.
> socket_clear_error($msgsock);
> break 2;
> }
> $parse_buffer .= $socket_buffer;
> $socket_buffer = '';
> //Now parse whatever we've got so far, leaving behind any partial record,
> //but only if we've got at least one full record to start with.
> while (strlen($parse_buffer) >= 4009)){
> $record = unpack($format, $parse_buffer);
> print_r($record);
> $parse_buffer = substr($parse_buffer, 4009); //4010?
> }
> }
>
> The point being that you can't expect to get a full record when you only
> read 2048 bytes at a time, and then you can't expect to find record
> boundaries if you then parse only half of a record and "move on" to the
> "next" record when you only got half a record, and then at that point
> you're getting just under half of the first record, plus a little bit of
> the second record...
Makes some sense, I just didn't see it to be a problem at this point,
but maybe it is... I also think that the server is NULL padding the
buffer up to the 4K limit after all of the text is stored in it. (I'll
have to check to validate my theory here).
>
> Actually, since you know each record is exactly 4009 bytes long, you might
> wanna change your buffer size from 2048 to 4009 (or 4010 if that's what
> works) and simplify the code a lot.
>
> Course, if they ever re-define #define REPLY_MSG_SIZE 4000 then you'll
> have to adjust, so you probably should express everything in terms of your
> own REPLY_MSG_SIZE as well, using a http://php.net/define and then writing
> things like REPLY_MSG_SIZE + 8 or REPLY_MSG_SIZE + 8 + 1 for the places
> where you need to add to get to the byte you want.
Always a good idea for production code..."They" in this case is ME
anyway! So I'll have no one to blame but myself should this ever occur.
>
> Hope all of that makes sense and is of some use...
Make sense, don't know if it'll help yet, but I'm fixin to try some of
your suggestions. Thanks again.
--
Scott E. Young
Area Mgr - NMA Software Solutions
sy9286@xxxxxxx
(713) 567-8625
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
