in reply to recv byte length problem?

What the docs actually say is: 
SCALAR will be grown or shrunk to the length actually read.

[download]
I take this to mean that SCALAR will have the number of bytes read, but not regardless of LENGTH. If the number of bytes read is less than LENGTH (e.g. the socket has closed), then the length of SCALAR will be less then LENGTH as well. If however, there are more bytes in the socket's buffer than LENGTH, SCALAR will contain LENGTH bytes, and the remaining bytes stay in the socket buffer.

So, the actually read part is specified for the case where you read less bytes than LENGTH.

As to dynamically increasing LENGTH, I do not know what you mean exactly, but you can specify a different length in different recv()'s: 

recv($socket, $string1, 512, 0);
recv($socket, $string2, 256, 0):

[download]

CU
Robartes- hoping this makes some sense

Replies are listed 'Best First'.
Re: Re: recv byte length problem?
by peschkaj (Pilgrim) on Nov 06, 2002 at 16:11 UTC

    Ah, that makes sense. I mis-read it to mean that SCALAR will be the same size as the message received. Although, your explanation makes much more sense than my interperetation.

    When I wrote about dynamically increasing length I wasn't terribly clear. Sorry.

    What I really should have asked is: Should I set my LENGTH quite high to provide for future capabilities, or should I, instead, make sure that I size LENGTH appropriately now and determine an effective protocol to use that is verbose enough to deal with anything I can throw at it?

    In retrospect it's a silly question and I should go with the latter of the two solutions: settle on a specific size of message to accept and write code accordingly.

    Thanks, ++Robartes.

    If you make something idiot-proof, eventually someone will make a better idiot.
    I am that better idiot.
[reply]

In Section Seekers of Perl Wisdom