Re: Server script through inetd

Assuming you don't have $/ set, the problem may be that perl is receiving a partial line from the read or recv it uses. Recall that even though it looks like a read from a keyboard, it is reading from a socket. The TCP protocol does not necessarily deliver data in the chunks (e.g. lines) in which it was sent. There are no data boundries in TCP (use UDP for that). While the camel book examples just use

while($line = <SOCK>)
[download]

to read, they read small messages.

In general, when you read from a TCP socket you need to be sure you got a whole message (a line in your case) and continue reading until you can verify that you got the whole message.

You can test with something like this:

$| = 1; # remove buffering
while($input = <STDIN>){
    # maybe process the input
    print $input;
}
[download]

--traveler </code>

Comment on Re: Server script through inetd Select or Download Code

Replies are listed 'Best First'.
(tye)Re: Server script through inetd by tye (Sage) on Jul 25, 2001 at 23:48 UTC
I don't believe that is the problem. If Perl gets partial data from a socket and that partial data doesn't contain the current value of $/, then `<STDIN>` is going to issue another read until it either gets a string that contains the current value of $/ or it gets end-of-file. (Well, that is my impression and testing confirms it but the perl source code involved is quite complex with lots of possible routes through the code depending on `#ifdef`s and big ifs, so there may be some cases where this doesn't happen -- if so, I'd appreciate validation of this fact.) But, in general, this feature usually ends up being a good reason to not use `<SOCK>` to read from sockets. Certainly, if you do use `<SOCK>` to read from sockets, be sure to have $/ set appropriately. For this case, I would think that "appropriately" would mean having $/ set to undef so that `<STDIN>` reads until end-of-file. But that strategy won't work unless the client requests that end-of-file be sent by using shutdown. But then, if the client doesn't use shutdown than the server has no reliable way to determine when all of the data has been received and it would have to resort to some sort of timeout logic. evilstevel, feel free to provide more details if our guessing hasn't helped yet. (: - tye (but my friends call me "Tye")	[reply] [d/l] [select]

Replies are listed 'Best First'.

(tye)Re: Server script through inetd
by tye (Sage) on Jul 25, 2001 at 23:48 UTC

I don't believe that is the problem. If Perl gets partial data from a socket and that partial data doesn't contain the current value of $/, then <STDIN> is going to issue another read until it either gets a string that contains the current value of $/ or it gets end-of-file. (Well, that is my impression and testing confirms it but the perl source code involved is quite complex with lots of possible routes through the code depending on #ifdefs and big ifs, so there may be some cases where this doesn't happen -- if so, I'd appreciate validation of this fact.)

But, in general, this feature usually ends up being a good reason to not use <SOCK> to read from sockets. Certainly, if you do use <SOCK> to read from sockets, be sure to have $/ set appropriately.

For this case, I would think that "appropriately" would mean having $/ set to undef so that <STDIN> reads until end-of-file. But that strategy won't work unless the client requests that end-of-file be sent by using shutdown. But then, if the client doesn't use shutdown than the server has no reliable way to determine when all of the data has been received and it would have to resort to some sort of timeout logic.

evilstevel, feel free to provide more details if our guessing hasn't helped yet. (:

tye

[reply]
[d/l]
[select]