[19905] in Perl-Users-Digest
Perl-Users Digest, Issue: 2100 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri Nov 9 09:05:43 2001
Date: Fri, 9 Nov 2001 06:05:10 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <1005314710-v10-i2100@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Fri, 9 Nov 2001 Volume: 10 Number: 2100
Today's topics:
600 lines <agp-soft@t-online.de>
Re: 600 lines <bernard.el-hagin@lido-tech.net>
Re: 600 lines <bill.kemp@wire2.com>
Re: 600 lines (Rafael Garcia-Suarez)
Re: 600 lines <bernard.el-hagin@lido-tech.net>
Re: 600 lines <bill.kemp@wire2.com>
Re: 600 lines <bernard.el-hagin@lido-tech.net>
Re: 600 lines (Rafael Garcia-Suarez)
Re: 600 lines <bernard.el-hagin@lido-tech.net>
[ANNNOUNCE] SQL::QueryBuilder::Simple release <wlkngowl@unix.asb.com>
CGI::Safe 1.2 <cp@onsitetech.com>
Re: converting ^M characters to \n <j.w.haaring@azu.nl>
Re: Is it possible to convert a UNIX shell command into <tim@vegeta.ath.cx>
LWP::UserAgent <s.warhurst@rl.ac.uk>
Re: Need Some Help <swivelhitsmith@nowhere.com>
Re: Newbie Question <krahnj@acm.org>
Re: Using TCP "keep alives" with IO::Socket <real@earthling.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 9 Nov 2001 12:00:42 +0100
From: "Armin Bauer" <agp-soft@t-online.de>
Subject: 600 lines
Message-Id: <9sgd5f$h8a$07$1@news.t-online.com>
Hi!
I'm asking for a friend, who's doing Perl programming.
He has a problem. When his script becomes longer than 600 lines of code, the
perl interpreter tells him, that there's a syntax error. he tried to put
this code into a xyz.sub - file and require it but perl said, it was unable
to find the file...
Is it possible that this is a limitation of perl?
Armin Bauer
------------------------------
Date: 9 Nov 2001 11:18:40 GMT
From: Bernard El-Hagin <bernard.el-hagin@lido-tech.net>
Subject: Re: 600 lines
Message-Id: <slrn9unhum.mi5.bernard.el-hagin@gdndev25.lido-tech>
On Fri, 9 Nov 2001 12:00:42 +0100, Armin Bauer <agp-soft@t-online.de> wrote:
> Hi!
>
> I'm asking for a friend, who's doing Perl programming.
>
> He has a problem. When his script becomes longer than 600 lines of code, the
> perl interpreter tells him, that there's a syntax error. he tried to put
> this code into a xyz.sub - file and require it but perl said, it was unable
> to find the file...
>
> Is it possible that this is a limitation of perl?
That's the most ridiculous thing I've ever heard. Surely you don't
think that the syntax error is a direct result of exceeding 600 lines
of code, do you? If Larry Wall had set such a limit I bet it would
have been 666 lines, but not anything as ho-hum as 600.
Cheers,
Bernard
------------------------------
Date: Fri, 9 Nov 2001 11:25:44 -0000
From: "W K" <bill.kemp@wire2.com>
Subject: Re: 600 lines
Message-Id: <55PG7.87$yw1.957@news.uk.colt.net>
> > I'm asking for a friend, who's doing Perl programming.
> >
> > He has a problem. When his script becomes longer than 600 lines of code,
the
> > perl interpreter tells him, that there's a syntax error. he tried to put
> > this code into a xyz.sub - file and require it but perl said, it was
unable
> > to find the file...
> >
> > Is it possible that this is a limitation of perl?
>
>
> That's the most ridiculous thing I've ever heard. Surely you don't
> think that the syntax error is a direct result of exceeding 600 lines
> of code, do you? If Larry Wall had set such a limit I bet it would
> have been 666 lines, but not anything as ho-hum as 600.
How to make 777 lines of useless code:
$ perl -e ' for(1..777){print "\$i++; print \"hello $_ \$i\\n\";\n" }'
>777.pl
$ perl -c 777.pl
777.pl syntax OK
What's the 601st line then?
------------------------------
Date: 9 Nov 2001 11:26:21 GMT
From: rgarciasuarez@free.fr (Rafael Garcia-Suarez)
Subject: Re: 600 lines
Message-Id: <slrn9unfbr.idv.rgarciasuarez@rafael.kazibao.net>
Bernard El-Hagin wrote in comp.lang.perl.misc:
> On Fri, 9 Nov 2001 12:00:42 +0100, Armin Bauer <agp-soft@t-online.de> wrote:
> > Hi!
> >
> > I'm asking for a friend, who's doing Perl programming.
> >
> > He has a problem. When his script becomes longer than 600 lines of code, the
> > perl interpreter tells him, that there's a syntax error. he tried to put
> > this code into a xyz.sub - file and require it but perl said, it was unable
> > to find the file...
> >
> > Is it possible that this is a limitation of perl?
>
>
> That's the most ridiculous thing I've ever heard. Surely you don't
> think that the syntax error is a direct result of exceeding 600 lines
> of code, do you? If Larry Wall had set such a limit I bet it would
> have been 666 lines, but not anything as ho-hum as 600.
May be related to the limitation on formats.
See perldiag/Runaway format.
--
Rafael Garcia-Suarez / http://rgarciasuarez.free.fr/
Much programming is best done with techniques that do not fall within a
narrow definition of "object-oriented." -- Bjarne Stroustrup
------------------------------
Date: 9 Nov 2001 11:32:36 GMT
From: Bernard El-Hagin <bernard.el-hagin@lido-tech.net>
Subject: Re: 600 lines
Message-Id: <slrn9unioq.mi5.bernard.el-hagin@gdndev25.lido-tech>
On Fri, 9 Nov 2001 11:25:44 -0000, W K <bill.kemp@wire2.com> wrote:
>> > I'm asking for a friend, who's doing Perl programming.
>> >
>> > He has a problem. When his script becomes longer than 600 lines of code,
> the
>> > perl interpreter tells him, that there's a syntax error. he tried to put
>> > this code into a xyz.sub - file and require it but perl said, it was
> unable
>> > to find the file...
>> >
>> > Is it possible that this is a limitation of perl?
>>
>>
>> That's the most ridiculous thing I've ever heard. Surely you don't
>> think that the syntax error is a direct result of exceeding 600 lines
>> of code, do you? If Larry Wall had set such a limit I bet it would
>> have been 666 lines, but not anything as ho-hum as 600.
>
> How to make 777 lines of useless code:
> $ perl -e ' for(1..777){print "\$i++; print \"hello $_ \$i\\n\";\n" }'
>>777.pl
> $ perl -c 777.pl
> 777.pl syntax OK
>
> What's the 601st line then?
$i++; print "hello 601 $i\n";
What's your point?
Cheers,
Bernard
------------------------------
Date: Fri, 9 Nov 2001 11:39:10 -0000
From: "W K" <bill.kemp@wire2.com>
Subject: Re: 600 lines
Message-Id: <HhPG7.90$yw1.946@news.uk.colt.net>
> >> > He has a problem. When his script becomes longer than 600 lines of
code,
> > the
> >> > perl interpreter tells him, that there's a syntax error. he tried to
put
> >
> > What's the 601st line then?
> What's your point?
point spread out in the post. sorry.
If the script goes wrong when its over 600 lines thats probably
(?certainly?) because you have just introduced an error in the last line you
added.
As simple a point as that I'm afraid.
------------------------------
Date: 9 Nov 2001 11:48:14 GMT
From: Bernard El-Hagin <bernard.el-hagin@lido-tech.net>
Subject: Re: 600 lines
Message-Id: <slrn9unjm4.mi5.bernard.el-hagin@gdndev25.lido-tech>
On Fri, 9 Nov 2001 11:39:10 -0000, W K <bill.kemp@wire2.com> wrote:
>> >> > He has a problem. When his script becomes longer than 600 lines of
> code,
>> > the
>> >> > perl interpreter tells him, that there's a syntax error. he tried to
> put
>
>> >
>> > What's the 601st line then?
>
>> What's your point?
>
> point spread out in the post. sorry.
>
> If the script goes wrong when its over 600 lines thats probably
> (?certainly?) because you have just introduced an error in the last line you
> added.
> As simple a point as that I'm afraid.
So why did the OP post the question? Because the OP thinks that there's
a limitation which causes the syntax error after exceeding 600 lines.
If the OP posts some code (just not the whole 600 lines please!) we can
try to find the error, but without the code all we can answer is - no,
Perl scripts are *not* limited to 600 lines.
Cheers,
Bernard
------------------------------
Date: 9 Nov 2001 12:27:59 GMT
From: rgarciasuarez@free.fr (Rafael Garcia-Suarez)
Subject: Re: 600 lines
Message-Id: <slrn9univb.igr.rgarciasuarez@rafael.kazibao.net>
Bernard El-Hagin wrote in comp.lang.perl.misc:
>
> So why did the OP post the question? Because the OP thinks that there's
> a limitation which causes the syntax error after exceeding 600 lines.
> If the OP posts some code (just not the whole 600 lines please!) we can
> try to find the error, but without the code all we can answer is - no,
> Perl scripts are *not* limited to 600 lines.
And the original problem is filtered through the OP, who is not a perl
programmer, but who is speaking for a friend. So we don't know either
what error is introduced by the 601th line.
Imagine that you post in comp.lang.basic.visual.3rdparty or in
alt.culture.macedonia.moderated on the behalf of a friend ?
--
Rafael Garcia-Suarez / http://rgarciasuarez.free.fr/
Removing old functionality is not unlike wearing a copper armour and
climbing to the top of tree in a lightning storm. -- Jarkko Hietaniemi
------------------------------
Date: 9 Nov 2001 12:39:12 GMT
From: Bernard El-Hagin <bernard.el-hagin@lido-tech.net>
Subject: Re: 600 lines
Message-Id: <slrn9unmlm.mi5.bernard.el-hagin@gdndev25.lido-tech>
On 9 Nov 2001 12:27:59 GMT, Rafael Garcia-Suarez <rgarciasuarez@free.fr> wrote:
> Bernard El-Hagin wrote in comp.lang.perl.misc:
>>
>> So why did the OP post the question? Because the OP thinks that there's
>> a limitation which causes the syntax error after exceeding 600 lines.
>> If the OP posts some code (just not the whole 600 lines please!) we can
>> try to find the error, but without the code all we can answer is - no,
>> Perl scripts are *not* limited to 600 lines.
>
> And the original problem is filtered through the OP, who is not a perl
> programmer, but who is speaking for a friend. So we don't know either
> what error is introduced by the 601th line.
So how can we help other than by answering the only question
which was posed? The OP will relay the replies to his Perl
programming chum and maybe he'll refine the query. I don't
think guessing what the OP's friend was getting at is the most
effective way of helping him.
> Imagine that you post in comp.lang.basic.visual.3rdparty or in
> alt.culture.macedonia.moderated on the behalf of a friend ?
As to the first I wouldn't admit I had a friend who programs in
VB. As to the second I'd do quite well, thank you. :-) But I know
what you're getting at, it's just that I still belive that we can't
answer a badly posed question. Call me crazy.
Cheers,
Bernard
------------------------------
Date: Thu, 08 Nov 2001 00:06:37 -0500
From: Robert Rothenburg <wlkngowl@unix.asb.com>
Subject: [ANNNOUNCE] SQL::QueryBuilder::Simple release
Message-Id: <tunf15tdj5umd9@corp.supernews.com>
NAME
SQL::QueryBuilder::Simple - Generates simple SQL SELECT queries
REQUIREMENTS
This module is written for and tested on Perl 5.6.0.
It uses only standard modules.
Installation
Installation is pretty standard:
perl Makefile.PL
make
make test
make install
SYNOPSIS
use SQL::QueryBuilder::Simple;
my $query = SQL::QueryBuilder::Simple->new(
table => "MYTABLE", # from table MYTABLE
fields => [ qw( FLD1 FLD2 ) ], # select fields FLD1, FLD2
ne => { FLD1 => -1 }, # where FLD1 not equal to -1
);
print $query->sql; # SELECT FLD1, FLD2 FROM MYTABLE WHERE FLD1<>?
use DBI;
my $dbh = DBI->connect( ... ) or die;
my $sth = $dbh->prepare( $query->sql ) or die;
$sth->execute( $query->bindings ) or die;
DESCRIPTION
This module generates simple SQL select statements and manages
binding
parameters, to simplify generating dynamic queries.
This module will only generate SQL code. It does not validate the
code,
nor does it check against any database to see if table or field
names
are valid.
See the module's POD and README for more detailed information.
AVAILABILITY
It should show up soon at a CPAN mirror near you in as:
$CPAN/authors/id/R/RR/RRWO/SQL-QueryBuilder-Simple-0.03.tar.gz
------------------------------
Date: 08 Nov 2001 21:17:25 GMT
From: "Curtis Poe" <cp@onsitetech.com>
Subject: CGI::Safe 1.2
Message-Id: <tunf0rctfsfnd4@corp.supernews.com>
At Lincoln Stein's suggestion, I will soon be uploading CGI::Safe 1.2 to the
CPAN. Until such time, you may download the documentation from
http://www.easystreet.com/~ovid/cgi_course/downloads/CGI-Safe-1.2.tgz
>From the email I sent requesting a PAUSE ID:
CGI::Safe - Safe method of using CGI.pm. This is pretty
much a two-line change for most CGI scripts.
This module is a subclass of CGI.pm. The intention is to
make the CGI programming environment safer. By default, it
sets $CGI::DISABLE_UPLOADS to 1 and $CGI::POST_MAX to 512k.
Additionally, it deletes @ENV{ qw/ IFS CDPATH ENV BASH_ENV / }
and $ENV{ PATH } to '/bin:/usr/bin' and, if it exists,
$ENV{ SHELL } to '/bin/sh'.
All of these behaviors may be overridden if needed.
Feel free to provide me with any feedback or suggestions for more tests.
Any POD errors would also be nice to know.
If any tests fail, or if you encounter any other problems, please let me
know your version of CGI.pm, Perl version, and operating system. Of course,
patches are always welcome ...
--
Cheers,
Curtis "Ovid" Poe
Senior Programmer
ONSITE! Technology
www.onsitetech.com
503.233.1418
------------------------------
Date: Fri, 09 Nov 2001 12:17:34 +0100
From: Jan-Willem <j.w.haaring@azu.nl>
Subject: Re: converting ^M characters to \n
Message-Id: <3BEBBB4E.C6DEA912@azu.nl>
hi,
> I have tried the following:
>
> open (OUTFILE) ">/tmp/mylist || die "cannot open";
> foreach $x (@MyData) {
> if ($x =~ /^M/ ) {
> $x =~ s/^M//;
> }
> print OUTFILE $x;
> print "\n";
> }
In this part you try to substitute the ^M character with a \n character.
Your current regex:
$x =~ s/^M//;
will modify all lines starting with a M and substitute the M by
-nothing- since the ^ is
a meta-character and does not literaly mean ^. You don't want that.
Besides that, $x =~ s/\^M//; will not work either because the ^M you
see in your file is
actually 0D0A in hex. This should do the trick:
$x =~ s/(\x0D\x0A)/\n/g;
The if-statement is unnecessary since the regex will only substitute
'if' a match is found.
Good luck!
Cheers,
Jan-Willem
------------------------------
Date: Fri, 09 Nov 2001 12:40:39 GMT
From: Tim Hammerquist <tim@vegeta.ath.cx>
Subject: Re: Is it possible to convert a UNIX shell command into PERL?
Message-Id: <slrn9unk56.or4.tim@vegeta.ath.cx>
Patrick Spinler <spinler.patrick@mayo.edu> graced us by uttering:
> Dan Nguyen wrote:
>>
>> I would like to convert one of the two lines below from UNIX shell into perl
>> but I was not able to do it.
>> Please HELP HELP HELP!
>>
>> find . -name "*.h" -follow -print | sed -e 's/^/\"/;s/$/\"/' | xargs
>> wc -l | sed '$\!d' | nawk '{print $1}'
>
> perl -MFile::Find -e 'File::Find::finddepth (sub {$lines += `wc -l $_`
> if ($_ =~ /\.h$/)}, "."); END { print "$lines\n" }'
>
> (forgive the bad wrapping, this was all one line)
>
> I'm not a perl guru so I'm certain someone can improve on this,
> especially in the speed of execution.
Perl comes with several standard conversion utilities: awk -> perl, sed
-> perl, find -> perl. They are covered in the manpages a2p(1), s2p(1),
find2perl(1), respectively.
The more general question of how to convert shell to perl is answered
in the perl faqs:
$ perldoc -q 'shell script'
To make full use of any of these utilities, you should have a good grasp
of perl. If you know awk, sed, or find well, the converters can teach
you a _little_ about how perl works.
Anyway, this should get you started.
Tim Hammerquist
--
Well of *course* Perl should not be taught to everyone. It should
only be taught to people who want to like their computers.
-- Larry Wall
------------------------------
Date: Fri, 9 Nov 2001 12:56:47 -0000
From: "S Warhurst" <s.warhurst@rl.ac.uk>
Subject: LWP::UserAgent
Message-Id: <9sgjqg$1796@newton.cc.rl.ac.uk>
Hi
I'm using LWP::UserAgent to send a http request to Listserv, eg:
[..]
$url =
http://www.blahblah.ac.uk/cgi-bin/wa.exe?LOGIN1=HDRED2=AUTO2%26C=1%26M=0%26H
=$formdata{preview}&Y=someone\@blahblah.ac.uk&p=password;
use LWP::UserAgent; $ua = new LWP::UserAgent;
$request = HTTP::Request->new(GET => $url);
[..]
$formdata{preview}contains the new header information I am sending to
Listserv. The header can contain various metacharacters, and it causing
problems, ie:
If $formdata{preview} contains a simple header such as this:
$formdata{preview} = "Auto2 list for discussion\n
Subscription= Open,Confirm\n
Reply-to= List,Respect\n
Send= Public\n
Owner= owner@blahblah.ac.uk\n
Notebook= Yes,e:\list-logs\auto2,Monthly,Private\n";
it sends OK and I don't need to escape the @'s or \'s. However, if the
header has a plus sign in, eg:
$formdata{preview} = "Auto2 list for discussion\n
Subscription= Open,Confirm\n
Reply-to= List,Respect\n
Send= Public\n
Owner= owner@blahblah.ac.uk\n
Notebook= Yes,e:\list-logs\auto2,Monthly,Private\n";
+++ for sysadmin use only+++
then Listserv updates the header OK, but completely loses the + signs,
replacing them with spaces. I've tried repacing the + signs as in -
$formdata{preview} =~ s/\+/\%2B/g; aswell, but it has no effect.
Some other metacharacters, such as &, can cause Listserv to thrown up an
error and not update the header at all. However, The list header has a
description which may validly include an & character, so I need to be able
to send them without Perl or Listserv faling over.
The other trouble is, that if I escape everything.. eg with:
$formdata{preview} = quotemeta $formdata{preview};
then I end up with loads of unwanted backslashes in the list header file,
and fo rthat matter line sthat sometimes exceed the 100 character
line-limit.
I suppose this is a fundamental error in the way I am sending the date, but
I can't for the life of me figure it out.
Spencer
------------------------------
Date: Fri, 09 Nov 2001 13:16:00 GMT
From: swivelhitsmith <swivelhitsmith@nowhere.com>
Subject: Re: Need Some Help
Message-Id: <rllnut0ba4p39endp76e7onep8lu36ht9c@4ax.com>
There are tons of modules on CPAN.
The books to buy (that have been invaluable for me) Perl Programming
3rd edition and Perl Cookbook.
On Fri, 9 Nov 2001 04:43:27 -0500, "Sophie Anderson"
<saUSAFirst@yahoo.com> wrote:
>I just started learning Perl a few hours ago at www.perl.com
>
>I have 3 databases or (files).
>
>db1.txt has fields:
>bNumber bName bPhone
>
>db2.txt has fields:
>bNumber ISBN returnDate
>
>db3.txt has fields:
>ISBN Author Title Publisher Cost Year
>
>I need to read all files so that when I type "Enter the borrower
>number: " all fields from all 3 fields are displayed.
>I could do this pretty easily in C/C++ but my boss want it in Perl
>claiming that Perl can handle files better.
>At www.perl.com I learned how to open/close files, put each line
>(record) into arrays, split the line into fields, etc. Also Perl uses
>regular expression to match field/record.
>
>My questions:
>How do read 3 files together? Should I use the sleep function? But how?
>
>Are there any Perl built in functions that I should know instead of
>spending limited time figuring out the codes?
>
>Is/are there any "worth to buy" Perl book(s) out there on files
>handling? (I have spent quite a lot of money buying useless books.)
>
>Your time and help are appreciated. Thank you very much in advance.
>
------------------------------
Date: Fri, 09 Nov 2001 11:56:31 GMT
From: "John W. Krahn" <krahnj@acm.org>
Subject: Re: Newbie Question
Message-Id: <3BEBC46B.91C14C13@acm.org>
Bernard El-Hagin wrote:
>
> On Fri, 9 Nov 2001 04:56:00 -0500, Adam Young <AdamYYYY@yahoo.com> wrote:
> > What does this pattern say?
> >
> > /(ABC).*(XYZ).*\1.*\2/
>
> ABC followed by a crapload of anything followed by XYZ followed
> by a crapload of anything followed by ABC followed by another
> crapload of anything followed by XYZ.
"crapload" here defined as zero or more of any character except newline
(\n). :-)
> Read 'perldoc perlre' and start placing the subjects of your posts
> in the cleverly named Subject fields.
John
--
use Perl;
program
fulfillment
------------------------------
Date: Fri, 9 Nov 2001 14:32:16 +0100
From: "Real" <real@earthling.net>
Subject: Re: Using TCP "keep alives" with IO::Socket
Message-Id: <9sglt2$i1d$1@news.surfnet.nl>
<nokesja@netscape.net> wrote in message
news:3beb2fdc.60bb.1804289383@opus.randori.com...
> Greetings,
> I've been scouring the internet, news, all the PerlFAQ's,
> PerlMonks, and every O'reilly book I have ... and I cannot
> find any article that discusses how to utilize the perl
> IO::Socket module and TCP 'keep-alives'. I have a
> home-grown application that speaks pure TCP/IP with the
> remote host, but the firewall in-between us keeps timing my
> application out, because there is a lot of idle time on the
> socket. We have many applications running through this
> firewall so we cannot change the time-out settings on it.
> Thus, I keep getting random socket drop offs every time the
> firewalll times out my connection.
>
> Since we have written our own extensive perl modules,
> incorporating the IO::Socket interface, it is too much
> trouble to change it. We have numerous network based apps
> using this module and changing it extensively means a year
> of regression testing. It would be less trouble to get a
> dedicated firewall for our problem. In the hopes of not
> having to spend the extra $$ on a new PIX, I'm trying to
> figure out how I can send 'keep-alive' packets via the
> IO::Socket::INET module.
>
> Can anyone help me shed some light on this?
>
> Thanks in advance.
> - Jeff
Hay Jeff,
My responce is all theori since I never implemented keep-alive but since
sockets have my interest I though to throw in my 2 cents.
You can try to implement the "setsockopt" SO_KEEPALIVE option. See "man
setsockopt" for a detailed description. Since you're not the only/first one
trying to setup such a thing, Google is a good source of information about
this topic. Below is a bunch of text I've found and it seems to describe
exactly what you want. Also not that the related TCP parameters are
OS-dependend. The command for displaying TCP related parameters on SunOS for
example is: /usr/sbin/ndd /dev/tcp '?'
Good luck,
Real
---------
Below is some doco on timers for tcpip and how they can be tuned.
The OS TCP/IP Keepalive option is a socket option set via the setsockopt()
call, described on pages 5-79/81 of OS TCP/IP Programmer's manual (R224).
The SO_KEEPALIVE option is used to determine if a peer process is no longer
in touch with Stratus, by the periodic transmission of a dummy ACK packet.
It has to be explicitly enabled for a TCP connection.
The defaults established for the keepalive mechanism allow for a 2-hour
period of inactivity on a connection set with the SO_KEEPALIVE option.
After this period, 8 probes will be done, 75 seconds apart, to check if
the correspondent is still 'alive'. If no response is received, the
connection will be taken down. For some users, this 2 hour 10 minute
interval is too long an interval to wait around.
There are 3 globally tunable parameters that specify time-ticks in units
of 500ms, i.e. 2 ticks per second. The external variables listed below
are all 32-bit numbers and require the
as: set_longword <new> -check <old>
command to change the current values:
1. tcpos_keepidle$ set to 14400 (3840x), i.e. 2 hours
which is the time a TCP connection has to be idle before
keep_alive probing is undertaken.
2. tcpos_keepintvl$ set to 150 (96x), i.e. 75 seconds
which is the interval between probes when begun
3. tcpos_maxidle$ set to 1200 (4B0x), i.e. 10 minutes
which is the total interval for which probing will continue
WITHOUT any peer response, i.e. for 8 probes worth. Note
that
tcpos_maxidle$ is expected to be an octuple of (i.e. 8 times
the value of) tcpos_keepintvl$ and does not control the
number of probes done (always a total of 8 attempts).
By default, the keepalive probing (if enabled) will start after 2 hours
on an idle TCP connection and will continue every 75 seconds thereafter
for 10 minutes, until some activity is encountered.
If the values are set to 8 minutes, 15 seconds and 120 seconds respectively,
a broken connection will be taken down after 10 minutes. On the other hand,
a good idling TCP connection will see A SINGLE ACK exchange every 8 minutes
of inactivity. It is this latter traffic that one has to be concerned about
in estimating the minimal performance impact of exchanging dummy ACK packets
on the network.
Any activity on the connection (including the exchange of the dummy ACKs)
will renew the inactivity timeout period (tcpos_keepidle$), so there is
no overhead on a steadily in-use connection.
Please let me know if this information answers your questions.
Plus this one
-------------------------------------------------------------
IEN: 124
DOD STANDARD
TRANSMISSION CONTROL PROTOCOL
December 1979
prepared for
Defense Advanced Research Projects Agency
Information Processing Techniques Office
1400 Wilson Boulevard
Arlington, Virginia 22209
by
Information Sciences Institute
University of Southern California
4676 Admiralty Way
Marina del Rey, California 90291
December 1979
Transmission Control Protocol
-------------------------------------------------------------
A connection progresses through a series of states during its
lifetime. The states are: LISTEN, SYN-SENT, SYN-RECEIVED,
ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2, TIME-WAIT, CLOSE-WAIT, CLOSING,
and the fictional state CLOSED. Closed is fictional because it
represents the state when there is no TCB, and therefore, no
connection. Briefly the meanings of the states are:
LISTEN - represents waiting for a connection request from any remote
TCP and port.
SYN-SENT - represents waiting for a matching connection request
after having sent a connection request.
SYN-RECEIVED - represents waiting for a confirming connection
request acknowledgment after having both sent and received a
connection request.
ESTABLISHED - represents an open connection, ready to transmit and
receive data segments.
FIN-WAIT-1 - represents waiting for a connection termination request
from the remote TCP, or an acknowledgment of the connection
termination request previously sent.
FIN-WAIT-2 - represents waiting for a connection termination request
from the remote TCP.
TIME-WAIT - represents waiting for enough time to pass to be sure
the remote TCP received the acknowledgment of its connection
termination request.
CLOSE-WAIT - represents waiting for a connection termination request
from the local user.
CLOSING - represents waiting for a connection termination request
acknowledgment from the remote TCP.
CLOSED - represents no connection state at all.
A TCP connection progresses from one state to another in response to
events. The events are the user calls, OPEN, SEND, RECEIVE, CLOSE,
ABORT, and STATUS; the incoming segments, particularly those
containing the SYN and FIN flags; and timeouts.
The Glossary contains a more complete list of terms and their
definitions.
The state diagram in figure 6 only illustrates state changes, together
with the causing events and resulting actions, but addresses neither
error conditions nor actions which are not connected with state
changes. In a later section, more detail is offered with respect to
the reaction of the TCP to events.
+---------+ ---------\ active OPEN
| CLOSED | \ -----------
+---------+<---------\ \ create TCB
| ^ \ \ snd SYN
passive OPEN | | CLOSE \ \
------------ | | ---------- \ \
create TCB | | delete TCB \ \
V | \ \
+---------+ CLOSE | \
| LISTEN | ---------- | |
+---------+ delete TCB | |
rcv SYN | | SEND | |
----------- | | ------- | V
+---------+ snd SYN,ACK / \ snd SYN +---------+
| |<----------------- ------------------>| |
| SYN | rcv SYN | SYN |
| RCVD |<-----------------------------------------------| SENT |
| | snd ACK | |
| |------------------ -------------------| |
+---------+ rcv ACK of SYN \ / rcv SYN,ACK +---------+
| -------------- | | -----------
| x | | snd ACK
| V V
| CLOSE +---------+
| ------- | ESTAB |
| snd FIN +---------+
| CLOSE | | rcv FIN
V ------- | | -------
+---------+ snd FIN / \ snd ACK +---------+
| FIN |<----------------- ------------------>| CLOSE |
| WAIT-1 |------------------ -------------------| WAIT |
+---------+ rcv FIN \ / CLOSE +---------+
| rcv ACK of FIN ------- | | -------
| -------------- snd ACK | | snd FIN
V x V V
+---------+ +---------+
|FINWAIT-2| | CLOSING | +---------+
+---------+
| rcv FIN | rcv ACK of FIN
| ------- Timeout=2MSL | --------------
V snd ACK ------------ V delete TCB
+---------+ delete TCB +---------+
|TIME WAIT|----------------->| CLOSED |
+---------+ +---------+
TCP Connection State Diagram
Figure 6.
------------------------------------------------------------------------
We note that the Internet Protocol provides arguments for a type
of service and for a time to live. TCP uses the following
settings for these parameters:
Type of Service = Precedence: none, Package: stream,
Reliability: higher, Preference: speed, Speed: higher; or
00011111.
Time to Live = one minute, or 00111100.
Note that the assumed maximum segment lifetime is two minutes.
Here we explicitly ask that a segment be destroyed if it
cannot be delivered by the internet system within one minute.
------------------------------------------------------------------------
3.7. Data Communication
Once the connection is established data is communicated by the
exchange of segments. Because segments may be lost due to errors
(checksum test failure), or network congestion, TCP uses
retransmission (after a timeout) to ensure delivery of every segment.
Duplicate segments may arrive due to network or TCP retransmission.
As discussed in the section on sequence numbers the TCP performs
certain tests on the sequence and acknowledgment numbers in the
segments to verify their acceptability.
The sender of data keeps track of the next sequence number to use in
the variable SND.NXT. The receiver of data keeps track of the next
sequence number to expect in the variable RCV.NXT. The sender of data
keeps track of the oldest unacknowledged sequence number in the
variable SND.UNA. If the data flow is momentarily idle and all data
sent has been acknowledged then the three variables will be equal.
When the sender creates a segment and transmits it the sender advances
SND.NXT. When the receiver accepts a segment it advances RCV.NXT and
sends an acknowledgment. When the data sender receives an
acknowledgment it advances SND.UNA. The extent to which the values of
these variables differ is a measure of the delay in the communication.
Normally the amount by which the variables are advanced is the length
of the data in the segment. However, when letters are used there are
special provisions for coordination the sequence numbers, the letter
boundaries, and the receive buffer boundaries.
------------------------------------------------------------------------
Concerning the different timeouts, I enclosed an example use of timeout
in the OPEN call:
Open
Format: OPEN (local port, foreign socket, active/passive
[, buffer size] [, timeout] [, precedence]
[, security/compartment]) -> local connection name
We assume that the local TCP is aware of the identity of the
processes it serves and will check the authority of the process
to use the connection specified. Depending upon the
implementation of the TCP, the local network and TCP identifiers
for the source address will either be supplied by the TCP or by
the processes that serve it (e.g., the program which interfaces
the TCP network). These considerations are the result of
concern about security, to the extent that no TCP be able to
masquerade as another one, and so on. Similarly, no process can
masquerade as another without the collusion of the TCP.
If the active/passive flag is set to passive, then this is a
call to LISTEN for an incoming connection. A passive open may
have either a fully specified foreign socket to wait for a
particular connection or an unspecified foreign socket to wait
for any call. A fully specified passive call can be made active
by the subsequent execution of a SEND.
A full-duplex transmission control block (TCB) is created and
partially filled in with data from the OPEN command parameters.
On an active OPEN command, the TCP will begin the procedure to
synchronize (i.e., establish) the connection at once.
The buffer size, if present, indicates that the caller will
always receive data from the connection in that size of buffers.
This buffer size is a measure of the buffer between the user and
the local TCP. The buffer size between the two TCPs may be
different.
The timeout, if present, permits the caller to set up a timeout
for all buffers transmitted on the connection. If a buffer is
not successfully delivered to the destination within the timeout
period, the TCP will abort the connection. The present global
default is 30 seconds. The buffer retransmission rate may vary;
most likely, it will be related to the measured time for
responses from the remote TCP.
The TCP or some component of the operating system will verify
the users authority to open a connection with the specified
precedence or security/compartment. The absence of precedence
or security/compartment specification in the OPEN call indicates
the default values should be used.
-----Original Message-----
From: blancof@sanborns.com.mx [mailto:blancof@sanborns.com.mx]
Sent: Tuesday, 8 August 2000 8:50
To: Info-Stratus@list.stratagy.com
Subject: IS:: time out for SO_KEEPALIVE
Hi all.
I'am programing TCP sockets.
Could someone help me on using SO_KEEPALIVE option?.
I need to turn on this option on an aplication but i need to change the time
out value. Is this posible ?
How can i do that ?. I'd checked the manual but I didn't find the answer.
VOS 14.02
Thanks in advance.
------------------------------
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:
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
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 V10 Issue 2100
***************************************
