Re: Chunked unix socket file reading

IO::Select will let you do a timed-wait for input.

This will avoid your reader hanging indefinitely, if for what ever reason you don't receive expected transmissions in full.

Haven't tested it here but the usage should be something like:

#!/usr/bin/perl
use common::sense;
use IO::Socket;
use IO::Select;

# establish connection
my $socket = IO::Socket::UNIX->new(
     Peer    => '/path/to/socket.file.sock',
    );

my $sel = IO::Select->new();
$sel->add($socket);

# issue command and read answer
my $some_command = 'foo';
print $socket "$some_command\n";
my $html = "<html>". sockread($sel,$socket). "</html>";

sub sockread {
    my $sel = shift;
    my $socket = shift;
    my $content;
    my $TimeOut = 0.5; #sec to wait

    while ($sel->can_read($TimeOut) && (my $line=<$socket>)){
        $content .= $line;
        last if $line =~ /\[ End of /i;         # vlc's rc is a bit in
+consistent, some end like this
        last if $line =~ / returned 0 /i;       # others like this
    }
    return $content;
}
[download]

Update: Corrected $TimeOut from ms to seconds.

Comment on Re: Chunked unix socket file reading - how? Select or Download Code

Replies are listed 'Best First'.
Re^2: Chunked unix socket file reading - how? by Anonymous Monk on Nov 18, 2009 at 21:01 UTC
@snoopy: timeout on can_read() is in seconds, not ms! Had more success with can_read(1), e.g.	[reply]
Re^3: Chunked unix socket file reading - how? by snoopy (Curate) on Nov 18, 2009 at 21:59 UTC
Quite right. IO::Select, passes the timeout straight through to the select function, which expects the units to be seconds, and can accept fractional quantities (e.g. 0.5). I've updated the code above.	[reply]
Re^2: Chunked unix socket file reading - how? by Anonymous Monk on Nov 18, 2009 at 19:56 UTC
You were too fast ;) I had that feeling that I hadn't looked into IO::Select enough... (Currently testing...)	[reply]
Re^2: Chunked unix socket file reading - how? by Anonymous Monk on Nov 18, 2009 at 20:26 UTC
Mmmh. Everything looked as if your code is the solution. Then came testing.... I still get these looong reads that completely timeout/block my cgi. Some connects work, a few times and then, nirvana. The cgi immediately returns when I kill the vlc process on the server side. Somehow I wonder if it's really my read that doesn't return or some hickup on the vlc side. Any tips on how I could make my socket reading/connection more robust, so that it cares less about stale sockets? (socat never seems to care..) Should I issue the "logout" command vlc provides inside the rc session on each socket connect-command-read-"logout" cycle via my cgi (this cgi will never see much hits) So that vlc knows better: "this client is connecting, asking one thing, then disconnects"? (I know this is lsightly off-perl-topic)	[reply]
Re^2: Chunked unix socket file reading - how? by Anonymous Monk on Nov 18, 2009 at 20:45 UTC
Further testing shows: it's actually not the read that blocks. It is the `my $socket = IO::Socket::UNIX->new( Peer => $sockfile );` that never returns! ~~Is there a mechanism like the "Reuse" on file sockets as well? Is it possible some kind of lock lies on the file?~~ Even more testing shows: when the sock gets stale like this, even socat isn't able to connect to it (it doesn't complain but vlc doesn't react via the socket anymore) Is this a vlc problem then?	[reply] [d/l]