Skip Menu |
 

This queue is for tickets about the IO-Socket-IP CPAN distribution.

Report information
The Basics
Id: 92075
Status: resolved
Priority: 0/
Queue: IO-Socket-IP

People
Owner: Nobody in particular
Requestors: dagolden [...] cpan.org
Cc: oleg [...] cpan.org
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: 0.32



Subject: Timeout parameter
MIME-Version: 1.0
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
Message-ID: <rt-4.0.18-22134-1389541220-356.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 241
Download (untitled) / with headers
text/plain 241b
The INCOMPATIBILITIES section lists the Timeout as an unsupported parameter. Can it be added? If so, that would help the "drop-in" support. If not, could the rationale for why not be added to the documentation for clarity? Thanks, David
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-22134-1389541220-356.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-22134-1389541220-356.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-3604-1389875582-316.92075-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 782
Download (untitled) / with headers
text/plain 782b
On Sun Jan 12 10:40:20 2014, DAGOLDEN wrote: Show quoted text
> The INCOMPATIBILITIES section lists the Timeout as an unsupported > parameter. Can it be added? If so, that would help the "drop-in" > support. If not, could the rationale for why not be added to the > documentation for clarity?
Turns out that all the Timeout functionallity itself is implemented by the base IO::Socket class, and thus actually applies to /any/ IO::Socket subclass. It is however not documented there, and instead mentioned briefly in passing in IO::Socket::INET, which doesn't do anything special to help implement it. There's therefore no need for IO::Socket::IP to document or mention it as it's simply some behaviour inherited from its superclass. I've just removed all mention of it instead. -- Paul Evans
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-3604-1389875582-316.92075-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-22134-1389541220-356.0-0-0 [...] rt.cpan.org> <rt-4.0.18-3604-1389875582-316.92075-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-15607-1408264055-319.92075-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 2427
Download (untitled) / with headers
text/plain 2.3k
On Thu Jan 16 07:33:02 2014, PEVANS wrote: Show quoted text
> On Sun Jan 12 10:40:20 2014, DAGOLDEN wrote:
> > The INCOMPATIBILITIES section lists the Timeout as an unsupported > > parameter. Can it be added? If so, that would help the "drop-in" > > support. If not, could the rationale for why not be added to the > > documentation for clarity?
> > Turns out that all the Timeout functionallity itself is implemented by > the base IO::Socket class, and thus actually applies to /any/ > IO::Socket subclass. It is however not documented there, and instead > mentioned briefly in passing in IO::Socket::INET, which doesn't do > anything special to help implement it. > > There's therefore no need for IO::Socket::IP to document or mention it > as it's simply some behaviour inherited from its superclass. I've just > removed all mention of it instead.
This is not totally correct. IO::Socket handles timeout inside connect() using IO::Select: https://metacpan.org/source/GBARR/IO-1.25/lib/IO/Socket.pm#L115 But IO::Socket::IP overloads this method. So, there is no timeout handling here Here is a test: use strict; use Test::More; use IO::Socket::INET; use IO::Socket::IP; use Time::HiRes; use constant { SLOW_HOST => '173.194.32.142', # google.com SLOW_PORT => 81 }; $SIG{ALRM} = sub { die "Alarmed\n"; }; for my $impl ('INET', 'IP') { eval { my $start = Time::HiRes::time; alarm(10); my $sock = "IO::Socket::$impl"->new(PeerHost => SLOW_HOST, PeerPort => SLOW_PORT, Timeout => 3); alarm(0); my $end = Time::HiRes::time; my $err = $@; ok(!$sock, "$impl: socket not created"); like($err, qr/timeout/i, "$impl: proper error") or diag $err; my $duration = $end - $start; ok($duration > 2 && $duration < 5, "$impl: timed out"); diag $duration; }; ok(!$@, "$impl: no exceptions") or diag $@; } done_testing(); __END__ which outputs: ok 1 - INET: socket not created ok 2 - INET: proper error ok 3 - INET: timed out ok 4 - INET: no exceptions # 3.00477385520935 not ok 5 - IP: no exceptions 1..5 # Failed test 'IP: no exceptions' # at timeout.pl line 32. # Alarmed # Looks like you failed 1 test of 5. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/5 subtests Test Summary Report ------------------- timeout.pl (Wstat: 256 Tests: 5 Failed: 1) Failed test: 5 Non-zero exit status: 1 Files=1, Tests=5, 13 wallclock secs ( 0.04 usr 0.00 sys + 0.08 cusr 0.02 csys = 0.14 CPU) Result: FAIL
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-22134-1389541220-356.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-22134-1389541220-356.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-31193-1409670906-791.92075-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 223
Download (untitled) / with headers
text/plain 223b
Ping. Paul, what are your thoughts on this? Even un(der)-documented, if we want this to be a drop-in replacement, it needs to match behaviors, and people do rely on timeout (even if it doesn't always do what they expect).
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-31193-1409670906-791.92075-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-22134-1389541220-356.0-0-0 [...] rt.cpan.org> <rt-4.0.18-31193-1409670906-791.92075-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-12854-1409672089-1529.92075-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 670
Download (untitled) / with headers
text/plain 670b
On Tue Sep 02 11:15:06 2014, DAGOLDEN wrote: Show quoted text
> Ping. > > Paul, what are your thoughts on this? Even un(der)-documented, if we > want this to be a drop-in replacement, it needs to match behaviors, > and people do rely on timeout (even if it doesn't always do what they > expect).
I can easily write some code I can guess is probably correct. I can even go as far as to test it on the platforms I have access to (ie. Linux). I won't be able to write a unit test that the smokers will be able to use, because I can't reliably create a socket in such a timeout state. It's not testable. Ergo I don't know how to test it, so I'm not sure how to proceed. -- Paul Evans
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-12854-1409672089-1529.92075-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-22134-1389541220-356.0-0-0 [...] rt.cpan.org> <rt-4.0.18-31193-1409670906-791.92075-0-0 [...] rt.cpan.org> <rt-4.0.18-12854-1409672089-1529.92075-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-17701-1409672307-962.92075-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 279
Download (untitled) / with headers
text/plain 279b
On Tue Sep 02 11:34:49 2014, PEVANS wrote: Show quoted text
> It's not testable. > > Ergo I don't know how to test it, so I'm not sure how to proceed.
As much as I love TDD, I think it's sometimes OK to write code we believe is correct, spot check it, and rely on bug reports from real users.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-12854-1409672089-1529.92075-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-22134-1389541220-356.0-0-0 [...] rt.cpan.org> <rt-4.0.18-31193-1409670906-791.92075-0-0 [...] rt.cpan.org> <rt-4.0.18-12854-1409672089-1529.92075-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-12854-1409673199-1871.92075-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 815
Download (untitled) / with headers
text/plain 815b
On Tue Sep 02 11:34:49 2014, PEVANS wrote: Show quoted text
> On Tue Sep 02 11:15:06 2014, DAGOLDEN wrote:
> > Ping. > > > > Paul, what are your thoughts on this? Even un(der)-documented, if we > > want this to be a drop-in replacement, it needs to match behaviors, > > and people do rely on timeout (even if it doesn't always do what they > > expect).
> > I can easily write some code I can guess is probably correct. I can > even go as far as to test it on the platforms I have access to (ie. > Linux). > > I won't be able to write a unit test that the smokers will be able to > use, because I can't reliably create a socket in such a timeout state. > It's not testable. > > Ergo I don't know how to test it, so I'm not sure how to proceed.
The variant how to create non-connectable socket: http://stackoverflow.com/a/904609
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-22134-1389541220-356.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-22134-1389541220-356.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-15676-1409931041-78.92075-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 966
Download (untitled) / with headers
text/plain 966b
So... Do we have a properly-clear semantic definition of what "Timeout" should actually do here? I know it's applying to just the connect() phase. But what does it mean in practice? We have /no/ way to apply a timeout to the getaddrinfo() phase, so if the user is trying to connect by hostname and the (e.g.) DNS resolver takes a long time, that won't work. Presuming we manage to resolve a candidate list of addresses to attempt, how should the timeout apply to these? Should it apply separately to each address candidate? Or should it apply just once overall to all of the connect() calls - if the first one fails due to timeout we'll just stop there and never try the others..? If it applies just once overall, surely we should subtract the time that the name resolve operation took from this, so that the timeout effectively applies to the entire resolve+connect operation..? Or what? I don't have a clear idea of what the thing should do. -- Paul Evans
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-15676-1409931041-78.92075-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-22134-1389541220-356.0-0-0 [...] rt.cpan.org> <rt-4.0.18-15676-1409931041-78.92075-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-15728-1409932393-1616.92075-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 832
Download (untitled) / with headers
text/plain 832b
On Fri Sep 05 11:30:41 2014, PEVANS wrote: Show quoted text
> Do we have a properly-clear semantic definition of what "Timeout" > should actually do here?
I would argue "as close to what IO::Socket::INET does as possible". Show quoted text
> We have /no/ way to apply a timeout to the getaddrinfo() phase,
So let's not try to do that. (Though google tells me about getaddrinfo_a in some glibc's... is that an option if available?) Show quoted text
> Presuming we manage to resolve a candidate list of addresses to > attempt, how should the timeout apply to these?
I like the idea of it applying once overall, but not including DNS resolution since that's not under user control. As long as that's documented, I think that's acceptable. If someone needs more control, they can do the resolution themselves and then call connect per address with whatever timeout they desire.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-15728-1409932393-1616.92075-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-22134-1389541220-356.0-0-0 [...] rt.cpan.org> <rt-4.0.18-15676-1409931041-78.92075-0-0 [...] rt.cpan.org> <rt-4.0.18-15728-1409932393-1616.92075-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-15896-1409932884-364.92075-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 1224
Download (untitled) / with headers
text/plain 1.1k
On Fri Sep 05 11:53:13 2014, DAGOLDEN wrote: Show quoted text
> On Fri Sep 05 11:30:41 2014, PEVANS wrote:
> > Do we have a properly-clear semantic definition of what "Timeout" > > should actually do here?
> > I would argue "as close to what IO::Socket::INET does as possible".
From reading the code, it would appear to be implemented by the 'connect' method itself, so it's applying per address. Show quoted text
> > We have /no/ way to apply a timeout to the getaddrinfo() phase,
> > So let's not try to do that. (Though google tells me about > getaddrinfo_a in some glibc's... is that an option if available?)
I'm not sure I want support a non-default option for "some Linux boxes" at the cost of every other OS not supporting it. Show quoted text
> > Presuming we manage to resolve a candidate list of addresses to > > attempt, how should the timeout apply to these?
> > I like the idea of it applying once overall, but not including DNS > resolution since that's not under user control. As long as that's > documented, I think that's acceptable. > > If someone needs more control, they can do the resolution themselves > and then call connect per address with whatever timeout they desire.
It seems this isn't what IO::Socket::INET does then. -- Paul Evans
MIME-Version: 1.0
X-Spam-Status: No, score=-5.266 tagged_above=-99.9 required=10 tests=[AWL=1.333, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_OUR_RT=-4, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
In-Reply-To: <rt-4.0.18-15896-1409932884-1806.92075-6-0 [...] rt.cpan.org>
X-Spam-Flag: NO
X-RT-Interface: API
References: <RT-Ticket-92075 [...] rt.cpan.org> <rt-4.0.18-22134-1389541220-356.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-15676-1409931041-78.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-15728-1409932393-1616.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-15896-1409932884-1806.92075-6-0 [...] rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
X-Received: by 10.152.203.167 with SMTP id kr7mr12968050lac.75.1409933462272; Fri, 05 Sep 2014 09:11:02 -0700 (PDT)
Message-ID: <CAOeq1c-6t3LmNduB-ASJuN4ynri8Pk-1-7PCPXJn6OBgyXQwZQ [...] mail.gmail.com>
Content-Type: multipart/alternative; boundary="001a1134652e2d111b050253b729"
X-Spam-Score: -5.266
Authentication-Results: hipster.bestpractical.com (amavisd-new); dkim=pass header.i= [...] autopragmatic.com
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id E55B3240403 for <cpan-bug+IO-Socket-IP [...] hipster.bestpractical.com>; Fri, 5 Sep 2014 12:11:11 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMXGOHnxkMLy for <cpan-bug+IO-Socket-IP [...] hipster.bestpractical.com>; Fri, 5 Sep 2014 12:11:10 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id F2F1C2404CF for <bug-IO-Socket-IP [...] rt.cpan.org>; Fri, 5 Sep 2014 12:11:09 -0400 (EDT)
Received: (qmail 2252 invoked by alias); 5 Sep 2014 16:11:09 -0000
Received: from mail-la0-f47.google.com (HELO mail-la0-f47.google.com) (209.85.215.47) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Fri, 05 Sep 2014 09:11:07 -0700
Received: by mail-la0-f47.google.com with SMTP id el20so5663670lab.34 for <bug-IO-Socket-IP [...] rt.cpan.org>; Fri, 05 Sep 2014 09:11:02 -0700 (PDT)
Received: by 10.152.130.101 with HTTP; Fri, 5 Sep 2014 09:10:32 -0700 (PDT)
Delivered-To: cpan-bug+IO-Socket-IP [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #92075] Timeout parameter
Return-Path: <david [...] autopragmatic.com>
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=autopragmatic.com; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type; bh=nEfFZK1zq1Tu/4YGNWrya1BQH4tzufruCkQPtJhGLmI=; b=DcvEXkV/8TSfZaQ3O1o/Iwi5kA8sW0tCyfdVfoVjz41PGpvoxeVUvR3rHbUBAMpFAa mhjusmXrykMmWf+8xhw2D1voKX4VYOSgovaV9vWpYeDLfYUKcCif29yqWBr0/FQ/GCzB lsY3Rg2SkCQZnydd2Ur72Tbl36wCff8v6ZbAk=
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: cpan-bug+IO-Socket-IP [...] hipster.bestpractical.com
X-RT-Mail-Extension: io-socket-ip
X-Google-Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-type; bh=nEfFZK1zq1Tu/4YGNWrya1BQH4tzufruCkQPtJhGLmI=; b=m7eF4fHKZLpv78DR3fLzhk0XrWXxd+QJppuszt03b41KE/WvrtvdWtnkhx33AAuHA5 LCqlO1dE+Eiq6uaUcwopqY2aVuGpqkJOf6LuwlvvNXQpzACkE3Day/V64eOVKOSVappQ 8nSY3R8q55IAZsHyZ1sLoiVUJtvdPSg13k0hN4O9L7F6rqXg++2Y/N8oB6gPLa4RgLPw jfpz0SqTFEvtFTnqnzheAc1E+KgKUnTixXeUUTi03MCOC4OxVztGyYBvSDgOjpcN4Vqg 6spNF2/8uuwUfZMveUos9afiNLOjq4CRzsNYZsq7/mVJGDJARaP52L7WkaXsdS4np5fz 7oBA==
X-Google-Sender-Auth: bmY9XZ9xiQTbubzdMLPPryRaF7o
Sender: david [...] autopragmatic.com
Date: Fri, 5 Sep 2014 12:10:32 -0400
X-Spam-Level:
To: bug-IO-Socket-IP [...] rt.cpan.org
X-GM-Message-State: ALoCoQmhfjP9Rp2dAcen5TLzMH0HyOGI+DLYXdFeL5EnzKyaj99ZFSq6ufw0vMdXj5Opm/9ck93m
From: David Golden <dagolden [...] cpan.org>
RT-Message-ID: <rt-4.0.18-19166-1409933472-245.92075-0-0 [...] rt.cpan.org>
Content-Length: 0
content-type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Content-Length: 328
Download (untitled) / with headers
text/plain 328b
On Fri, Sep 5, 2014 at 12:01 PM, Paul Evans via RT < bug-IO-Socket-IP@rt.cpan.org> wrote: Show quoted text
> From reading the code, it would appear to be implemented by the 'connect' > method itself, so it's applying per address. > >
Then I suggest doing that. It wasn't clear to me in the code since I didn't see the loop per address. David
content-type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-RT-Original-Encoding: utf-8
Content-Length: 705
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-19166-1409933472-245.92075-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <RT-Ticket-92075 [...] rt.cpan.org> <rt-4.0.18-22134-1389541220-356.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-15676-1409931041-78.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-15728-1409932393-1616.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-15896-1409932884-1806.92075-6-0 [...] rt.cpan.org> <CAOeq1c-6t3LmNduB-ASJuN4ynri8Pk-1-7PCPXJn6OBgyXQwZQ [...] mail.gmail.com> <rt-4.0.18-19166-1409933472-245.92075-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-1971-1409939043-1779.92075-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 98
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-1971-1409939043-1779.92075-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <RT-Ticket-92075 [...] rt.cpan.org> <rt-4.0.18-22134-1389541220-356.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-15676-1409931041-78.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-15728-1409932393-1616.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-15896-1409932884-1806.92075-6-0 [...] rt.cpan.org> <CAOeq1c-6t3LmNduB-ASJuN4ynri8Pk-1-7PCPXJn6OBgyXQwZQ [...] mail.gmail.com> <rt-4.0.18-19166-1409933472-245.92075-0-0 [...] rt.cpan.org> <rt-4.0.18-1971-1409939043-1779.92075-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-10767-1410067320-1224.92075-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 1233
Download (untitled) / with headers
text/plain 1.2k
On Fri Sep 05 13:44:03 2014, PEVANS wrote: Show quoted text
The behavior when both Blocking => 0 and Timeout specified not compatible with IO::Socket::INET: time perl -Ilib -MIO::Socket::IP -E 'IO::Socket::IP->new(Blocking => 0, PeerAddr => "google.com", PeerPort => 81, Timeout => 5) or die $@' real 0m0.097s user 0m0.076s sys 0m0.012s perl -MIO::Socket::INET -E 'IO::Socket::INET->new(Blocking => 0, PeerAddr => "google.com", PeerPort => 81, Timeout => 5) or die $@' IO::Socket::INET: connect: timeout at -e line 1. real 0m5.095s user 0m0.064s sys 0m0.020s As you can see for this case IO::Socket::INET makes blocking connection with timeout. IO::Socket::IP just returns immediately. Don't know about others but I widely used this behaviour, for example: https://metacpan.org/source/OLEG/Net-Proxy-Type-0.08/lib/Net/Proxy/Type.pm#L575 Looks like typo in the docs: -This behviour is copied directly form `IO::Socket::INET'; for +This behviour is copied directly from `IO::Socket::INET'; for P.S. Hmm, how can I subscribe to this bug, so I can receive notifications about new messages?
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-10767-1410067320-1224.92075-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <RT-Ticket-92075 [...] rt.cpan.org> <rt-4.0.18-22134-1389541220-356.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-15676-1409931041-78.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-15728-1409932393-1616.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-15896-1409932884-1806.92075-6-0 [...] rt.cpan.org> <CAOeq1c-6t3LmNduB-ASJuN4ynri8Pk-1-7PCPXJn6OBgyXQwZQ [...] mail.gmail.com> <rt-4.0.18-19166-1409933472-245.92075-0-0 [...] rt.cpan.org> <rt-4.0.18-1971-1409939043-1779.92075-0-0 [...] rt.cpan.org> <rt-4.0.18-10767-1410067320-1224.92075-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-22554-1410167137-1170.92075-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 2117
On Sun Sep 07 01:22:00 2014, OLEG wrote: Show quoted text
> The behavior when both Blocking => 0 and Timeout specified not > compatible with IO::Socket::INET: > > time perl -Ilib -MIO::Socket::IP -E 'IO::Socket::IP->new(Blocking => > 0, PeerAddr => "google.com", PeerPort => 81, Timeout => 5) or die $@' > > real 0m0.097s > user 0m0.076s > sys 0m0.012s > > perl -MIO::Socket::INET -E 'IO::Socket::INET->new(Blocking => 0, > PeerAddr => "google.com", PeerPort => 81, Timeout => 5) or die $@' > IO::Socket::INET: connect: timeout at -e line 1. > > real 0m5.095s > user 0m0.064s > sys 0m0.020s > > As you can see for this case IO::Socket::INET makes blocking > connection with timeout. IO::Socket::IP just returns immediately. > Don't know about others but I widely used this behaviour, for example: > https://metacpan.org/source/OLEG/Net-Proxy-Type- > 0.08/lib/Net/Proxy/Type.pm#L575
Yes; I see it looks different, but I notice that IO::Socket::INET doesn't specify the interaction between Blocking and Timeout. Having read the implementation it does look as if that's an unintended bug - the implementor of timeouts in sub connect having just forgotten about the nonblocking case. I consider the behaviour in IO::Socket::IP to be more useful - that 'Blocking' determines if connect will block or just return immediately; if Timeout is also specified it determines the maximum time that it will block for, if it choses to block at all. My advice here would be simply not to specify both 'Blocking => 0' and a Timeout - if you want to perform nonblocking IO -after- the connect, you can do that simply by my $sock = $class->new( PeerAddr => ..., Timeout => $TIME ) or die "Cannot connect - $@"; $sock->blocking( 0 ); which will behave the same for IO::Socket::IP or ::INET Show quoted text
> Looks like typo in the docs: > -This behviour is copied directly form `IO::Socket::INET'; for > +This behviour is copied directly from `IO::Socket::INET'; for
Thanks, fixed. Show quoted text
> P.S. > Hmm, how can I subscribe to this bug, so I can receive notifications > about new messages?
Add yourself to the 'cc' list -- Paul Evans
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-22554-1410167137-1170.92075-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <RT-Ticket-92075 [...] rt.cpan.org> <rt-4.0.18-22134-1389541220-356.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-15676-1409931041-78.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-15728-1409932393-1616.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-15896-1409932884-1806.92075-6-0 [...] rt.cpan.org> <CAOeq1c-6t3LmNduB-ASJuN4ynri8Pk-1-7PCPXJn6OBgyXQwZQ [...] mail.gmail.com> <rt-4.0.18-19166-1409933472-245.92075-0-0 [...] rt.cpan.org> <rt-4.0.18-1971-1409939043-1779.92075-0-0 [...] rt.cpan.org> <rt-4.0.18-10767-1410067320-1224.92075-0-0 [...] rt.cpan.org> <rt-4.0.18-22554-1410167137-1170.92075-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-6107-1410167662-1053.92075-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 418
Download (untitled) / with headers
text/plain 418b
Show quoted text
> My advice here would be simply not to specify both 'Blocking => 0' and > a Timeout - if you want to perform nonblocking IO -after- the connect, > you can do that simply by > > my $sock = $class->new( PeerAddr => ..., Timeout => $TIME ) > or die "Cannot connect - $@"; > $sock->blocking( 0 ); >
For me IO::Socket::INET's behavior is more like a feature and not a bug. My vote would be to implement same behavior.
CC: oleg [...] cpan.org
MIME-Version: 1.0
X-Spam-Status: No, score=-5.399 tagged_above=-99.9 required=10 tests=[AWL=1.200, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FROM_OUR_RT=-4, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
In-Reply-To: <rt-4.0.18-22554-1410167138-1180.92075-6-0 [...] rt.cpan.org>
X-Spam-Flag: NO
X-RT-Interface: API
References: <RT-Ticket-92075 [...] rt.cpan.org> <rt-4.0.18-22134-1389541220-356.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-15676-1409931041-78.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-15728-1409932393-1616.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-15896-1409932884-1806.92075-6-0 [...] rt.cpan.org> <CAOeq1c-6t3LmNduB-ASJuN4ynri8Pk-1-7PCPXJn6OBgyXQwZQ [...] mail.gmail.com> <rt-4.0.18-19166-1409933472-245.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-1971-1409939043-1779.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-10767-1410067320-1224.92075-6-0 [...] rt.cpan.org> <rt-4.0.18-22554-1410167138-1180.92075-6-0 [...] rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
X-Received: by 10.112.24.104 with SMTP id t8mr28870565lbf.46.1410190214750; Mon, 08 Sep 2014 08:30:14 -0700 (PDT)
Message-ID: <CAOeq1c-zpvZ5-9Uw90oMxUOJ=LSV+G1m5UGFY_gnYde=daib7w [...] mail.gmail.com>
Content-Type: multipart/alternative; boundary="001a11344544d0fad705028f7e73"
X-Spam-Score: -5.399
Authentication-Results: hipster.bestpractical.com (amavisd-new); dkim=pass header.i= [...] autopragmatic.com
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 51D9624045B for <cpan-bug+IO-Socket-IP [...] hipster.bestpractical.com>; Mon, 8 Sep 2014 11:30:32 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xQe6N90wwn8L for <cpan-bug+IO-Socket-IP [...] hipster.bestpractical.com>; Mon, 8 Sep 2014 11:30:27 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 2C6FC240434 for <bug-IO-Socket-IP [...] rt.cpan.org>; Mon, 8 Sep 2014 11:30:26 -0400 (EDT)
Received: (qmail 27251 invoked by alias); 8 Sep 2014 15:30:26 -0000
Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com) (209.85.215.45) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Mon, 08 Sep 2014 08:30:21 -0700
Received: by mail-la0-f45.google.com with SMTP id pn19so17711995lab.32 for <bug-IO-Socket-IP [...] rt.cpan.org>; Mon, 08 Sep 2014 08:30:15 -0700 (PDT)
Received: by 10.152.130.101 with HTTP; Mon, 8 Sep 2014 08:29:43 -0700 (PDT)
Delivered-To: cpan-bug+IO-Socket-IP [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #92075] Timeout parameter
Return-Path: <david [...] autopragmatic.com>
Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=autopragmatic.com; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=xMkU7/fOoOE94xhQmeYN+/e9tFLZyHp5sxAeUcnZ2Rk=; b=RrIQU5dH9z0QwuIHjyjLgfI0OLFrfNtZzqrZjDTF7ff6H9d27l/S6rEwLLg3fh1dA6 iSsB3beqvglCYFqbgeRTVB/WgepG2Oq7WWjP3z3ERraCUiWd/GjYFLjCGY+J5alfPqdb lWmISgfF/ZZ9cD5hz815f1Tp/J8/M7SDgJHXU=
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: cpan-bug+IO-Socket-IP [...] hipster.bestpractical.com
X-RT-Mail-Extension: io-socket-ip
X-Google-Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-type; bh=xMkU7/fOoOE94xhQmeYN+/e9tFLZyHp5sxAeUcnZ2Rk=; b=FJ1uCst965Kc44BH9DF28T/yhHMLR/cNye0rB6lXDzKbw67PAJbFPAa+YYCoKdYdtX 600lR7/syUstWd24wgeoxyF3rP6NFLGdGnK+JCQByTicyAk/NDlTAcdzVDpaoHuLX9Ef 9/aykAqhtDTbXJM7orJBLxyVsuGItEItqyPzRPhh5e/VOLr9xFYzy3/U5TIdvYDHC4/m eC4VScNu1BL8q9bK3cfe1sxbRJRZtfUs2hKfeHOVSCmok4pFdqiOXEpeUynBABX7dNh4 M8gvAGgb5JWbP71i6MQgGXgFBBR3o9G7qo2S8AHXthyO3ok3GNFakFCcfcEZYnPjBzar saBQ==
X-Google-Sender-Auth: uZqkWtodDz5UcO8Z4Q83CjsUIVg
Sender: david [...] autopragmatic.com
Date: Mon, 8 Sep 2014 11:29:43 -0400
X-Spam-Level:
To: bug-IO-Socket-IP [...] rt.cpan.org
X-GM-Message-State: ALoCoQmNtZ1xPY4acMtNDRRT5YjeO2VdyJ68Y2nvmjQL0qujb/zkpYWCa8OEGhr1ywX3OoOqn6qL
From: David Golden <dagolden [...] cpan.org>
RT-Message-ID: <rt-4.0.18-8161-1410190233-1801.92075-0-0 [...] rt.cpan.org>
Content-Length: 0
content-type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Content-Length: 170
Download (untitled) / with headers
text/plain 170b
I'm with Paul on the Blocking/Timeout case. If I say "non-blocking" then I want it actually non-blocking, not "non-blocking, but only after blocking to connect". David
content-type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-RT-Original-Encoding: utf-8
Content-Length: 226
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-22134-1389541220-356.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-22134-1389541220-356.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-4814-1410616405-1125.92075-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 157
Download (untitled) / with headers
text/plain 157b
This is now implemented in 0.32, with documentation explaining the slight difference from ::INET with regards to Blocking => 0 with Timeout. -- Paul Evans


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.