[31471] in Perl-Users-Digest
Perl-Users Digest, Issue: 2723 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Dec 15 21:09:42 2009
Date: Tue, 15 Dec 2009 18:09:10 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Tue, 15 Dec 2009 Volume: 11 Number: 2723
Today's topics:
Curious benchmark results with Inline::C <jl_post@hotmail.com>
Re: Get remote IP in self-calling script <john@castleamber.com>
Re: Get remote IP in self-calling script <glex_no-spam@qwest-spam-no.invalid>
Re: Get remote IP in self-calling script <dimke.fax@uni.de>
Re: Get remote IP in self-calling script (Randal L. Schwartz)
Re: Get remote IP in self-calling script <john@castleamber.com>
push integers from strings <user@example.net>
Re: push integers from strings <ben@morrow.me.uk>
Re: Simple loop error (Bradley K. Sherman)
Re: Trying to avoid passing params to subs through glob <source@netcom.com>
Re: Trying to avoid passing params to subs through glob <uri@StemSystems.com>
Re: Trying to avoid passing params to subs through glob <source@netcom.com>
Re: Trying to avoid passing params to subs through glob <ben@morrow.me.uk>
Re: Want to judge some remote hosts online or not quick <spamtotrash@toomuchfiction.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 15 Dec 2009 16:35:43 -0800 (PST)
From: "jl_post@hotmail.com" <jl_post@hotmail.com>
Subject: Curious benchmark results with Inline::C
Message-Id: <ee63a7ad-cf56-49d5-8cda-4cbd6c63628f@u8g2000prd.googlegroups.com>
Hi,
I've recently been toying around with Inline::C, benchmarking
certain variations of C and Perl and examining the results.
I was curious about the performance penalty of calling an extra
function, so I created three different (but similar C functions). All
of them use the Pythagorean theorem to calculate the average distance
from the origin for all points with integer coordinates from 1 to
100. However, one function calls distance() to compute the distance,
another is the same except that it calls an inlined function, and the
other doesn't use a distance() function -- it just uses the "unrolled"
code, calling the distance logic in place of the function.
I theorized that the "unrolled" code would be the fastest, followed
by the code that called the inlined function, followed by the code
that called the non-inlined function.
However, to my surprise, when I benchmarked the code, I saw that
the code with the non-inlined function ran consistently faster, while
the other two sets of code ran at about the same speed, with the code
that doesn't call the function being a little faster than the code
that called the inline function.
If you're curious, here is the code I used:
#!/usr/bin/perl
use strict;
use warnings;
use Inline 'C' => <<'END_OF_C_CODE';
/* Given a set of integer coordinates, this function
* calculates the distance from the origin. */
double distance(int x, int y)
{
return sqrt(x*x + y*y);
}
/* Same as distance(), but declared inline. */
inline double inline_distance(int x, int y)
{
return sqrt(x*x + y*y);
}
/* This function loops through all integer coordinates
* from (1,1) to (100,100) and returns the average
* distance from the origin. The distance is computed
* without calling distance() nor inline_distance(). */
double c_unrolled()
{
int x, y;
int numEntries = 0;
double total = 0;
for (x = 1; x <= 100; x++)
{
for (y = 1; y <= 100; y++)
{
total += sqrt(x*x + y*y);
numEntries++;
}
}
return total/numEntries;
}
/* Same as c_unrolled(), except that the distance
* from the origin is computed with distance(). */
double c_with_function()
{
int x, y;
int numEntries = 0;
double total = 0;
for (x = 1; x <= 100; x++)
{
for (y = 1; y <= 100; y++)
{
total += distance(x, y);
numEntries++;
}
}
return total/numEntries;
}
/* Same as c_with_function(), except that the distance
* from the origin is computed with inline_distance(). */
double c_with_inline()
{
int x, y;
int numEntries = 0;
double total = 0;
for (x = 1; x <= 100; x++)
{
for (y = 1; y <= 100; y++)
{
total += inline_distance(x, y);
numEntries++;
}
}
return total/numEntries;
}
END_OF_C_CODE
die "Usage: perl $0 <NUM_TIMES_TO_TEST>\n",
"Sample usage: perl $0 10_000\n"
unless @ARGV == 1;
my ($count) = @ARGV;
$count =~ tr/_//d; # remove all '_' characters
use Benchmark ':all', ':hireswallclock';
my $results = timethese($count, {
'C unrolled' => 'c_unrolled()',
'C with function' => 'c_with_function()',
'C with inline' => 'c_with_inline()',
});
cmpthese($results);
__END__
When I ran this code with the following command:
perl extra_function_c.pl 100_000
I got the following as output:
Rate C with inline C unrolled C with
function
C with inline 11090/s -- -0%
-11%
C unrolled 11130/s 0% --
-10%
C with function 12422/s 12% 12%
--
So calling the C code that made use of an extra function call was
actually faster! But why is this so?
In case anyone wants to know, my "gcc -v" output is:
Reading specs from C:/strawberry/c/bin/../lib/gcc/mingw32/3.4.5/specs
Configured with: ../gcc-3.4.5-20060117-3/configure --with-gcc --with-
gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --
enable-threads --disable-nls --enable-languages=c,c+
+,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-
sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --
enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --
enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.5 (mingw-vista special r3)
Still curious, I created an all-C file that contained the C code in
my Perl script (on the same platform). When I compiled, ran, and
timed it, I saw that the C code without the function call was the
fastest (while the C code that used the inline function was the
slowest). This is in contrast to the Perl Benchmark findings, which
say that the function with the non-inlined function call was the
fastest.
(Incidentally, I searched on the web as to why the code that called
the inlined function might be slowest, and I discovered that inlining
functions doesn't necessarily make the code any faster. This might
explain why it's always the slowest when benchmarking.)
So I'm curious if other people also see similar results as mine
when running the above Perl script. And if so, why would the C code
with the extra function call be consistently faster in Perl (while not
in straight C)? The fact that the code with the extra function call
is faster seems counter-intuitive to me, no matter what platform I'm
using.
Thanks in advance for any advice, tips, or general wisdom.
-- Jean-Luc
------------------------------
Date: Tue, 15 Dec 2009 13:41:13 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: Get remote IP in self-calling script
Message-Id: <873a3cja92.fsf@castleamber.com>
"Markus R." Keßler <dimke.fax@uni.de> writes:
> "https://ssl1.fritsch-hosting.de/www.dipl-ing-kessler.de/cgi-bin/diary.pl"
[...]
> Or, is this normal behaviour when running https / mod_ssl? - The box is a
> "lamp" machine with apache and several virtual servers with shared IPs,
> mod_ssl, perl etc., running on debian.
You can have only one "https domain" on a given IP address [1]. What
seems to happen here is that fritsch-hosting.de proxies the other
domains via the single "https domain". The keyword is proxy here, which
means that Apache calls your script as part of the proxying, and hence
the server's IP address showing up.
[1] http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts
--
John Bokma
Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/
------------------------------
Date: Tue, 15 Dec 2009 17:07:04 -0600
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: Get remote IP in self-calling script
Message-Id: <4b281699$0$48220$815e3792@news.qwest.net>
Markus R. Keßler wrote:
> Am Mon, 14 Dec 2009 23:59:49 +0100 schrieb Jochen Lehmeier:
>
>> On Mon, 14 Dec 2009 23:49:39 +0100, Markus R. Keßler <dimke.fax@uni.de>
>> wrote:
>>
>>> And the following line, when clicking on "submit" the "remote address"
>>> environment variable contains the IP of the server.
>> How is that possible? If the user clicks "submit", the user's browser
>> connects to your Apache, which logs the remote IP (all this does not
>> involve Perl yet, as your web server will log independent from what
>> happens inside the CGI script).
>>
>>> Any idea how to get the "real" IP at _any_ time the script is called
>>> directly or indirectly?
>> The remote IP should already be logged, and a workaround should
>> absolutely not be necessary.
>>
>> Maybe you could make your code as short as possible (i.e., reduce
>> everything to the barest minimum of stuff; only one input field etc.).
>> Post your perl code together with the two form HTML page (the first one,
>> which is displayed when there are no CGI parameters) and the log file
>> snippet for the two requests. Then we can take a look at it.
>
> Hi all,
>
> many thanks for all your hints and info!
Many thanks for again, not posting your example code.
>
> Well, after reading your comments I already had the suspicion that this
> effect most likely could have something to do with a half- assed
> implementation of an SSL certificate.
>
> And in fact to load a page via ssl, no matter if html or perl, the
> customers of my ISP have to write the prefix
>
> "https://ssl1.fritsch-hosting.de/"
>
> in front of the url to, for instance, read
>
> "https://ssl1.fritsch-hosting.de/www.dipl-ing-kessler.de/cgi-bin/diary.pl"
>
> Experimentally I just removed this "prefix" and invoked the script over
> http rather than https - and in this case every demanded file is logged
> correctly!
Is the SSL traffic logged to a different file?
>
> Well, I just have no clue what goes on "inside" this SSL implementation
> and why apache behaves like this. Also, I have no idea how to get this
> box to behave correctly with SSL.
Maybe you need to talk to your ISP/hosting company?
There's plenty of documentation online for setting up SSL too.
Really, though, it's very likely you are making this much more
difficult than it needs to be. If you want to get help with
your code, then show your code. Without it, we can only
guess at the problem and wasting our time.
------------------------------
Date: 15 Dec 2009 23:47:56 GMT
From: "Markus R." =?iso-8859-1?q?Ke=DFler?= <dimke.fax@uni.de>
Subject: Re: Get remote IP in self-calling script
Message-Id: <4b28202b$0$7630$9b4e6d93@newsspool1.arcor-online.net>
Am Tue, 15 Dec 2009 17:07:04 -0600 schrieb J. Gleixner:
> Markus R. Keßler wrote:
>> Am Mon, 14 Dec 2009 23:59:49 +0100 schrieb Jochen Lehmeier:
>>
>>> On Mon, 14 Dec 2009 23:49:39 +0100, Markus R. Keßler
>>> <dimke.fax@uni.de> wrote:
>>>
>>>> And the following line, when clicking on "submit" the "remote
>>>> address" environment variable contains the IP of the server.
>>> How is that possible? If the user clicks "submit", the user's browser
>>> connects to your Apache, which logs the remote IP (all this does not
>>> involve Perl yet, as your web server will log independent from what
>>> happens inside the CGI script).
>>>
>>>> Any idea how to get the "real" IP at _any_ time the script is called
>>>> directly or indirectly?
>>> The remote IP should already be logged, and a workaround should
>>> absolutely not be necessary.
>>>
>>> Maybe you could make your code as short as possible (i.e., reduce
>>> everything to the barest minimum of stuff; only one input field etc.).
>>> Post your perl code together with the two form HTML page (the first
>>> one, which is displayed when there are no CGI parameters) and the log
>>> file snippet for the two requests. Then we can take a look at it.
>>
>> Hi all,
>>
>> many thanks for all your hints and info!
>
> Many thanks for again, not posting your example code.
Hi,
I just hesitated som time before posting the code because I haven't had
the chance to completely translate it into English. A version with code
in English but comments in German :-) is here:
http://www.dipl-ing-kessler.de/temp/sample.pl.txt
Hope, it's clear, though.
>> Well, after reading your comments I already had the suspicion that this
>> effect most likely could have something to do with a half- assed
>> implementation of an SSL certificate.
>>
>> And in fact to load a page via ssl, no matter if html or perl, the
>> customers of my ISP have to write the prefix
>>
>> "https://ssl1.fritsch-hosting.de/"
>>
>> in front of the url to, for instance, read
>>
>> "https://ssl1.fritsch-hosting.de/www.dipl-ing-kessler.de/cgi-bin/
diary.pl"
>>
>> Experimentally I just removed this "prefix" and invoked the script over
>> http rather than https - and in this case every demanded file is logged
>> correctly!
>
> Is the SSL traffic logged to a different file?
Don't know exactly. And, in contrary to what
http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts
says, our ISP _IS_ able to provide SSL to every "v-host"- customer. but
we had been told, that providing the same certificate to all the
customers is a quick and dirty hack. We should be glad that this works at
all.
>> Well, I just have no clue what goes on "inside" this SSL implementation
>> and why apache behaves like this. Also, I have no idea how to get this
>> box to behave correctly with SSL.
>
> Maybe you need to talk to your ISP/hosting company?
Well, see above...
> There's plenty of documentation online for setting up SSL too.
>
> Really, though, it's very likely you are making this much more difficult
> than it needs to be. If you want to get help with your code, then show
> your code. Without it, we can only guess at the problem and wasting our
> time.
Yes, sure. Thanks again,
best regards,
Markus
--
Please reply to group only.
For private email please use http://www.dipl-ing-kessler.de/email.htm
------------------------------
Date: Tue, 15 Dec 2009 16:41:44 -0800
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Get remote IP in self-calling script
Message-Id: <86tyvr6987.fsf@blue.stonehenge.com>
>>>>> "Markus" == Markus R <Keßler <dimke.fax@uni.de>> writes:
Markus> When the script is invoked without parameter if creates the neccessary
Markus> html code for a kind of input mask for entering the text, as well as the
Markus> buttons for "send" etc. So there's no need for a html file creating the
Markus> input form and from which the script is invoked.
I've written hundreds of scripts like that.
My columns at http://www.stonehenge.com/merlyn/columns.html are on line.
Probably 75 of the 255 there "use CGI" for this.
Markus> It _does_ work, so far.
Markus> But, because the script is called from itself, $ENV{'REMOTE_ADDR'} always
Markus> writes the IP of the _SERVER_ into the logfile, rather than the user's
Markus> one :-(
And this is where I lost you.
If your script invoked without parameters prints:
<form action="/path/to/me"> ... </form>
and the browser submits it, you should get the proper REMOTE_ADDR.
Something is not as you say. Maybe you explained it further down the thread,
but I think the thread got a bit distracted.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
------------------------------
Date: Tue, 15 Dec 2009 19:41:15 -0600
From: John Bokma <john@castleamber.com>
Subject: Re: Get remote IP in self-calling script
Message-Id: <87k4wnelvo.fsf@castleamber.com>
"Markus R." Keßler <dimke.fax@uni.de> writes:
> Don't know exactly. And, in contrary to what
>
> http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#vhosts
>
> says, our ISP _IS_ able to provide SSL to every "v-host"- customer.
Then why do you have to use:
https://ssl1.fritsch-hosting.de/www.dipl-ing-kessler.de/cgi-bin/diary.pl
^^^^^^^^^^^^^^^^^^
instead of
https://www.dipl-ing-kessler.de/cgi-bin/diary.pl
;-). (Exactly!)[1]
Like I wrote: my best guess is that Fritsch Hosting uses
ssl1.fritsch-hosting.de as a proxy for their customers to provide
https which results in Apache connecting to dipl-ing-kessler.de, hence
the address of the server showing up since ssl1.fritsch-hosting.de and
www.dipl-ing-kessler.de are on the same server (correct?).
[1]
www.dipl-ing-kessler.de uses an invalid security certificate.
The certificate is only valid for ssl1.fritsch-hosting.de
--
John Bokma
Read my blog: http://johnbokma.com/
Hire me (Perl/Python): http://castleamber.com/
------------------------------
Date: Tue, 15 Dec 2009 20:27:37 -0500
From: monkeys paw <user@example.net>
Subject: push integers from strings
Message-Id: <m-2dnTQ0XojmqrXWnZ2dnUVZ_qqdnZ2d@insightbb.com>
Following code has quoted numbers in it, but i want
just integers. What's easiest way?
# Translate the var $nums into an integer list
use strict;
my @allnums;
my $nums ='30-32,34,50,54-56';
my @nums = split /,/, $nums;
for my $numstr (@nums) {
if ($numstr =~ /-/) {
my ($lower, $upper) = split /-/, $numstr ;
for my $anum ($lower .. $upper) {
push @allnums, $anum;
}
} else {
push @allnums, $numstr;
}
}
use Data::Dumper;die 'DDDEBUG' . Dumper(\@allnums);
#Numbers 34 and 50 below have quote around them but i dont want it.
DDDEBUG$VAR1 = [
30,
31,
32,
'34',
'50',
54,
55,
56
];
------------------------------
Date: Wed, 16 Dec 2009 01:40:13 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: push integers from strings
Message-Id: <tcqlv6-b071.ln1@osiris.mauzo.dyndns.org>
Quoth monkeys paw <user@example.net>:
> Following code has quoted numbers in it, but i want
> just integers. What's easiest way?
You have an X-Y problem. This is where you are asking for X, because you
think it is what you need for Y, but you are mistaken. What are you
actually trying to do? There are very few circumstances in Perl where
you need to care about a scalar's internal storage format (and all of
those are considered unfixable bugs rather than features).
Ben
------------------------------
Date: Tue, 15 Dec 2009 20:26:04 +0000 (UTC)
From: bks@panix.com (Bradley K. Sherman)
Subject: Re: Simple loop error
Message-Id: <hg8rcr$774$2@reader1.panix.com>
In article <4b2793be$3$fuzhry+tra$mr2ice@news.patriot.net>,
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> wrote:
>In <hg6hkc$2ql$2@reader1.panix.com>, on 12/14/2009
> at 11:27 PM, bks@panix.com (Bradley K. Sherman) said:
>
>>The original message
>
>That would be Message-ID: <cQPUm.29534$3M1.8149@newsfe18.ams2>.
>
>>The original message begins in this manner:
>>>>>>>The following code does not print 1,
>
>That much is correct.
>
>>and the reason it does not is because of the equality operator.
>
>Which part of 'No; "<=" is not an equality operator.' don't you
>understand?
The = part. That's why we say "less than or equal". It's
equivalent to ! ( i > j) which is also two operations, but
in that case, neither is equality. HTH.
--bks
------------------------------
Date: Tue, 15 Dec 2009 14:32:48 -0800
From: David Harmon <source@netcom.com>
Subject: Re: Trying to avoid passing params to subs through globals
Message-Id: <if2dnUDjzOBhk7XWnZ2dnUVZ_sSdnZ2d@earthlink.com>
On Tue, 15 Dec 2009 03:19:11 -0500 in comp.lang.perl.misc, "Uri Guttman"
<uri@StemSystems.com> wrote,
>>>>>> "DH" == David Harmon <source@netcom.com> writes:
>
> DH> my $result = try_foo()
> DH> || try_bar()
> DH> || ... ;
>
> DH> handle_success( $result ) if $result;
>
>and how would you handle undef values? or a list return there? undef can
>be checked with // in 5.10 but lists can't be handled with ||. the loop
>version can easily be modified to handle list returns.
There is no indication that any of those things are needed. You are
moving the goalpost. Let the subroutines return 0 on failure. Or, the
above can _more_ easily be modified using the appropriate expression if
one of them cannot be altered.
>also if you need to pass args to those subs it gets redundant to see
>them in each call and noisy as well. the loop version keeps the calling
>code simple and extendable while keeping the list of calls separate
>where you can easily see and edit it.
If the subs need args then most likely they need different args.
How are you going to accommodate that in the loop version?
>this assumes a decent sized list of calls, not just 2 or 3 of them.
My list of calls is no uglier than your array list for any size.
But mainly it is straightforward and easily understood code, eliminating
all that loopyness for a task that is not much like a loop to begin
with. Consider it as a response to the elseif version, as yours was,
and then maybe you will like it more.
------------------------------
Date: Tue, 15 Dec 2009 18:59:11 -0500
From: "Uri Guttman" <uri@StemSystems.com>
Subject: Re: Trying to avoid passing params to subs through globals
Message-Id: <878wd3n60g.fsf@quad.sysarch.com>
>>>>> "DH" == David Harmon <source@netcom.com> writes:
DH> On Tue, 15 Dec 2009 03:19:11 -0500 in comp.lang.perl.misc, "Uri Guttman"
DH> <uri@StemSystems.com> wrote,
>>>>>>> "DH" == David Harmon <source@netcom.com> writes:
>>
DH> my $result = try_foo()
DH> || try_bar()
DH> || ... ;
>>
DH> handle_success( $result ) if $result;
>>
>> and how would you handle undef values? or a list return there? undef can
>> be checked with // in 5.10 but lists can't be handled with ||. the loop
>> version can easily be modified to handle list returns.
DH> There is no indication that any of those things are needed. You are
DH> moving the goalpost. Let the subroutines return 0 on failure. Or, the
DH> above can _more_ easily be modified using the appropriate expression if
DH> one of them cannot be altered.
i have seen too many subs which return undef on fail. in older perls
that is problematic with ||.
>> also if you need to pass args to those subs it gets redundant to see
>> them in each call and noisy as well. the loop version keeps the calling
>> code simple and extendable while keeping the list of calls separate
>> where you can easily see and edit it.
DH> If the subs need args then most likely they need different args.
DH> How are you going to accommodate that in the loop version?
a hash ref and a table of hashes (probably along with the sub
call). this is called table driven code and i have very nice working
examples of it in the test code in Sort::Maker on cpan. you can create
tables of args, expected return values, golden sort code, etc. it
removes tons of redundant code and makes it much easier to make
variations than if you did a standard if/else tree.
>> this assumes a decent sized list of calls, not just 2 or 3 of them.
DH> My list of calls is no uglier than your array list for any size.
for some definition of ugly. i will take mine. my perl eyes are very
experienced and used by many others for business.
DH> But mainly it is straightforward and easily understood code, eliminating
DH> all that loopyness for a task that is not much like a loop to begin
DH> with. Consider it as a response to the elseif version, as yours was,
DH> and then maybe you will like it more.
a long || list can be very annoying to some. it has several weaknesses
and it is inflexible. i don't prefer it so that is all i have to say.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.sysarch.com --
----- Perl Code Review , Architecture, Development, Training, Support ------
--------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
------------------------------
Date: Tue, 15 Dec 2009 17:32:04 -0800
From: David Harmon <source@netcom.com>
Subject: Re: Trying to avoid passing params to subs through globals
Message-Id: <qNWdnT4i6s0IpbXWnZ2dnUVZ_qVi4p2d@earthlink.com>
On Tue, 15 Dec 2009 18:59:11 -0500 in comp.lang.perl.misc, "Uri Guttman"
<uri@StemSystems.com> wrote,
>i have seen too many subs which return undef on fail. in older perls
>that is problematic with ||.
Thanks, I will have to watch out for that.
------------------------------
Date: Wed, 16 Dec 2009 01:41:24 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Trying to avoid passing params to subs through globals
Message-Id: <4fqlv6-b071.ln1@osiris.mauzo.dyndns.org>
Quoth "Uri Guttman" <uri@StemSystems.com>:
>
> i have seen too many subs which return undef on fail. in older perls
> that is problematic with ||.
Can you explain how? AFAIK undef has always been false...
Ben
------------------------------
Date: Tue, 15 Dec 2009 21:57:32 +0000 (UTC)
From: Kevin Collins <spamtotrash@toomuchfiction.com>
Subject: Re: Want to judge some remote hosts online or not quickly over WAN.
Message-Id: <slrnhig1jn.r9.spamtotrash@vai.unix-guy.com>
On 2009-12-12, Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> On 2009-12-11 19:45, Kevin Collins <spamtotrash@toomuchfiction.com> wrote:
>> On 2009-12-04, smallpond <smallpond@juno.com> wrote:
>>> On Dec 4, 8:28 am, Hongyi Zhao <hongyi.z...@gmail.com> wrote:
>>>> I want to judge some remote hosts online or not quickly over WAN. I've
>>>> learned that ping command will not work in this case if the icmp ack
>>>> is blocked locally by firewall. Is it possiable for me to do this job
>>>> by perl codes?
>>>
>>>
>>> So the problem is that they are online but you aren't.
>>> There is no valid reason to block ICMP packets.
>>
>> Really? Lots of people do...
>
> Lots of people don't understand what they are doing.
>
>> I believe the idea is to prevent ping floods.
>
> To prevent ping floods you need to block ICMP echo requests to broadcast
> addresses (or just don't reply to them) - blocking echo requests to
> unicast adresses gains you (or the victim) nothing.
>
> Anyway the idea is more that some people think that they can't be
> attacked if they hide.
My point being that the OP has a valid point, regardless of whether it makes
sense or not :)
Kevin
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V11 Issue 2723
***************************************
