[20006] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 2201 Volume: 10

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sun Nov 25 09:05:37 2001

Date: Sun, 25 Nov 2001 06:05:07 -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: <1006697106-v10-i2201@ruby.oce.orst.edu>
Content-Type: text

Perl-Users Digest           Sun, 25 Nov 2001     Volume: 10 Number: 2201

Today's topics:
        10 by 10 (error results?) <perl@cableone.net>
        [Newbie] Iterating through dirs recursively <assafl@flashnetworks.com>
    Re: [Newbie] Iterating through dirs recursively <wolfram.pfeiffer@bigfoot.com>
    Re: A Perl Bug? <jake@chaogic.com>
    Re: A Perl Bug? <admin@asarian-host.net>
    Re: A Perl Bug? <admin@asarian-host.net>
    Re: A Perl Bug? <bart.lateur@pandora.be>
    Re: A Perl Bug? <bart.lateur@pandora.be>
    Re: A Perl Bug? <admin@asarian-host.net>
    Re: Creating a Perl app.  Help with installation? <comdog@panix.com>
    Re: File locking question <J.E.J.opdenBrouw@st.hhs.nl>
    Re: file locking. <perl@cableone.net>
    Re: Newbie OO/Inheritance question (Randal L. Schwartz)
        pack (venus)
    Re: pack <wuerz@yahoo.com>
    Re: Using TCP "keep alives" with IO::Socket (Jeff Nokes)
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Sun, 25 Nov 2001 05:08:23 -0600
From: "Jason Gray" <perl@cableone.net>
Subject: 10 by 10 (error results?)
Message-Id: <u01ka7l90m2cf6@corp.supernews.com>

Hi, I am having trouble once again with my 10 by 10 results, for some reason
when i click the "See more" link in my code it gives it an awkward position
everytime, its reading from the files position though, is there anyway i can
fix this? To view an example, go here:
http://www.jayb.net/cgi-bin/cgiwrap/jayb/pp/test.pl,

My following code:

&parse($seperator);

my $DB = "data.txt";
my ($pos, @matches, $last_loc, $more);

print "Content-type: text/html\n\n";

open FILE, $DB or die "can't read $DB: $!";
seek FILE, $pos, 0 if $pos = $in{'pos'};
while (<FILE>) {
  chomp(my @fields = split /\\n/);
  if ($fields[0]) {
   $last_loc = tell(FILE) - length;  # get position
   push @matches, $fields[0];
   last if @matches == 11;  # yes, 11
  }
}
close FILE;

$more = @matches == 11 and pop @matches;

print map{ $_, "<br>" } @matches;

$last_loc -= 1;

more_button($last_loc) if $more;

sub more_button {
  my ($pos) = @_;
  print "<br>See <a href=\"test.pl?pos=$pos\">more</a>.\n";
}


Regards,
Jason Gray

"Just Another Perl Programmer"




------------------------------

Date: Sun, 25 Nov 2001 11:24:41 +0200
From: "Assaf Lavie" <assafl@flashnetworks.com>
Subject: [Newbie] Iterating through dirs recursively
Message-Id: <9tqddb$i3g$1@news.att.net.il>

I have a recursive function that works on every file in a certain directory
and then calls itself for any sub-directory.
Question is: How do I begin to iterate over the sub-dir's files? Do I need
to change the working directory (how?), or can I simply do this:
(<$subdir/*>)?

Thanks, Assaf.






------------------------------

Date: 25 Nov 2001 10:23:26 GMT
From: Wolfram Pfeiffer <wolfram.pfeiffer@bigfoot.com>
Subject: Re: [Newbie] Iterating through dirs recursively
Message-Id: <9tqgqu$q3v$1@news.rz.uni-karlsruhe.de>

Assaf Lavie <assafl@flashnetworks.com> wrote:
> I have a recursive function that works on every file in a certain directory
> and then calls itself for any sub-directory.
> Question is: How do I begin to iterate over the sub-dir's files? Do I need
> to change the working directory (how?), or can I simply do this:
> (<$subdir/*>)?

You can change your working directory with 'chdir' (perldoc perlfunc).

You should have a look at File::Find, though, it probably already does
what you want to do.

Gruss,
Wolfram


------------------------------

Date: Sun, 25 Nov 2001 02:13:55 -0600
From: "Jake Fan" <jake@chaogic.com>
Subject: Re: A Perl Bug?
Message-Id: <9tq98i$6ii$1@Masala.CC.UH.EDU>

Thanks for the tutorial link.  I was only partially and vaguely aware of the
autovivification issue, now things are much clearer.  But still, why "$x[0]
||= ..." autovivifies, while "$x[0] = $x[0] || ..." doesn't?  Does not seem
consistent.

(ps/btw/lol/imho/ymmv/..., let's not start another flame war over the
"top-post" issue.  I have my own reasons for "top-posting" but let's just
call it different personal preference.  You don't have to agree with
people's different styles, but at least respect their choices.  After all,
one of the greatest spirits of the 'net, OSS, or even Perl is freedom and
choices.  TMTOWTDI.)


Uri Guttman <uri@stemsystems.com> wrote in message
news:x7itbz9vul.fsf@home.sysarch.com...
> > "JF" == Jake Fan <jake@chaogic.com> writes:
>
>   JF> Thanks for the quick reply.  It's quite informative.  Most of my
>   JF> Perl knowledge comes from the manpage (perldoc.com) and hands-on
>   JF> experiences.  As far as I remember there is not much info about
>   JF> the "autovivify" concept in the manpage.  Can you recommend
>   JF> additional reading material (or maybe the proper manpage I missed)
>   JF> before I hit Google?
>
> read my autovivify tutorial at:
>
> http://tlc.perlarchive.com/articles/perl/ug0002.shtml
>
>   JF> The code snippet was for illustration purposes only.  It may not
>   JF> be so weird in real life as I encountered the problem in a real
>   JF> world application.  I think the problem is a bit
>   JF> counter-intuitive, for people with little knowledge of the
>   JF> internals of Perl.  Considering "&&" takes precedence over "+=,
>   JF> .=, ||=" etc, the result of "$x[0] ||= !@x && 'x';" doesn't seem
>   JF> ambiguous -- until "autovivify" kicks in, that is.
>
> that is the hidden issue. you can't assign to $x[0] unless it is created
> first. then @x will be 1. remember ||= knows it will assign something to
> @x so it wants to allocate the element slot first for speed. there is
> no defined order that says the right side of = will be fully evaluated
> before the assignment.
>






------------------------------

Date: Sun, 25 Nov 2001 11:17:38 GMT
From: "Mark" <admin@asarian-host.net>
Subject: Re: A Perl Bug?
Message-Id: <mr4M7.36386$YD.3129036@news2.aus1.giganews.com>

"Uri Guttman" <uri@stemsystems.com> wrote in message
news:x7itbz9vul.fsf@home.sysarch.com...

> that is the hidden issue. you can't assign to $x[0] unless it is
> created first. then @x will be 1. remember ||= knows it will
> assign something to @x so it wants to allocate the element
> slot first for speed...

Interesting issue, this autovivify stuff. :) I found your article most
illuminating. Not pretending to know, but asking: what would happen with
this?

$x[0] ||= undef;

Not that such operation makes much sense; but just out of curiosity, would
it autovivify and then be undef-ed again? Or would perl see through this?

- Mark




------------------------------

Date: Sun, 25 Nov 2001 11:26:23 GMT
From: "Mark" <admin@asarian-host.net>
Subject: Re: A Perl Bug?
Message-Id: <zz4M7.56345$uB.9743645@bin3.nnrp.aus1.giganews.com>

"Mark" <admin@asarian-host.net> wrote in message
news:mr4M7.36386$YD.3129036@news2.aus1.giganews.com...

> "Uri Guttman" <uri@stemsystems.com> wrote in message
> news:x7itbz9vul.fsf@home.sysarch.com...
>
> > that is the hidden issue. you can't assign to $x[0] unless it is
> > created first. then @x will be 1. remember ||= knows it will
> > assign something to @x so it wants to allocate the element
> > slot first for speed...
>
> Interesting issue, this autovivify stuff. :) I found your article
> most illuminating. Not pretending to know, but asking: what
> would happen with this?
>
> $x[0] ||= undef;
>
> Not that such operation makes much sense; but just out of
> curiosity, would it autovivify and then be undef-ed again?
> Or would perl see through this?

Or would this still autovivify a "defined" for $x[0], but just undef its
content?

- Mark




------------------------------

Date: Sun, 25 Nov 2001 11:57:39 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: A Perl Bug?
Message-Id: <iqm10ukp5apf33h3k7n09bramb0srk8843@4ax.com>

Mark wrote:

>> $x[0] ||= undef;

>Or would this still autovivify a "defined" for $x[0], but just undef its
>content?

undef() is not defined. There's no way your program is supposed to know
the difference between an autovivifies element, or one which got
undeffed.

But somehow, Data::Dumper knows, and reports it. See:

	
	use Data::Dumper;
	my @x;
	$x[5] = undef;
	print  Dumper \@x;
-->
	$VAR1 = [
	          undef,
	          ${\$VAR1->[0]},
	          ${\$VAR1->[0]},
	          ${\$VAR1->[0]},
	          ${\$VAR1->[0]},
	          undef
	        ];

As you can see from the above, the first 5 elements ($x[5] is the sixth)
are all the same copy.

Oh, and as you may have deduced from the info in my other reply: "||="
makes the LHS autovivify before the RHS is evaluated. Whether this value
is undef or anything else, doesn't matter.

Another cute example:

	my @x;
	$x[0] ||= scalar @x;
	print $x[0];
-->
	1

Replace the "||=" with "=", and witness the difference.

-- 
	Bart.


------------------------------

Date: Sun, 25 Nov 2001 11:57:48 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: A Perl Bug?
Message-Id: <94m10uoqlvr3r6n5k2gkhs0d25g5r0i1o5@4ax.com>

Jake Fan wrote:

[last one:]

>$x[0] ||= !@x && "x";
>print "$x[0]\n";
>undef @x;

>Supposedly, all three code sections should do the same thing, but the last
>one didn't work out as expected.

It prints nothing... yes, that isn't *that* surprising to me. The reason
for that is that ||= is special. It makes sure that the LHS does indeed
exist (it springs to life as undef) before the RHS is evaluated.
Therefore, when you begin to evaluate the RHS, @x is no longer 0, and
!@x is the boolean false, which is the empty string in string context.
The "&&" returns that value as it is false and on the left.

Witness the difference:

	my(%x, %y);
	$x{aha} = scalar keys %x unless exists $x{aha};
	$y{aha} ||= scalar keys %y;
	print "\$x{aha} = $x{aha}\n\$y{aha} = $y{aha}\n";

(Note: the "scalar" is only there for clarity. keys() in scalar context
returns the number of keys.)

You seem to expect the same in %x and %y afterwards. Yet $x{aha} is 0,
$y{aha} is 1. Why?

Because 

	$y{aha} ||= ... 

makes $y{aha} spring to life (value = undef) if it didn't exist already
before the RHS is evaluated. Thus, at that time, keys %y contains one
entry, for "aha".

But

	$x{aha} = scalar keys %x unless exists $x{aha};

does not have the same effect. exists() doesn't make it exist, if it
didn't. Thus, at the time the RHS is evaluated, $x{aha} doesn't exist
yet, %x is still empty, keys %x returns 0. Only AFTER THAT, does $x{aha}
spring to life, and it gets the value of the expression: 0.

Is it documented somewhere? I don't know. I know this from experience.
When you think of it, it makes sense. It deserves to be documented.

-- 
	Bart.


------------------------------

Date: Sun, 25 Nov 2001 12:16:03 GMT
From: "Mark" <admin@asarian-host.net>
Subject: Re: A Perl Bug?
Message-Id: <7i5M7.114926$dk.8465674@bin1.nnrp.aus1.giganews.com>

"Bart Lateur" <bart.lateur@pandora.be> wrote in message
news:iqm10ukp5apf33h3k7n09bramb0srk8843@4ax.com...

> Mark wrote:
>
> >> $x[0] ||= undef;
>
> >Or would this still autovivify a "defined" for $x[0], but just undef
> >its content?
>
> undef() is not defined. There's no way your program is supposed to
> know the difference between an autovivifies element, or one which
> got undeffed.
>
> But somehow, Data::Dumper knows, and reports it. See:
>
>
> use Data::Dumper;
> my @x;
> $x[5] = undef;
> print  Dumper \@x;
> -->
> $VAR1 = [
>           undef,
>           ${\$VAR1->[0]},
>           ${\$VAR1->[0]},
>           ${\$VAR1->[0]},
>           ${\$VAR1->[0]},
>           undef
>         ];
>
> As you can see from the above, the first 5 elements ($x[5] is
> the sixth) are all the same copy.
>
> Oh, and as you may have deduced from the info in my other
> reply: "||=" makes the LHS autovivify before the RHS is
> evaluated. Whether this value is undef or anything
> else, doesn't matter.
>
> Another cute example:
>
> my @x;
> $x[0] ||= scalar @x;
> print $x[0];
> -->
> 1
>
> Replace the "||=" with "=", and witness the difference.

Thanks for the detailed explanation! It makes good sense to me now. There is
lots to be learned here (at least, by me).

- Mark




------------------------------

Date: Sun, 25 Nov 2001 03:33:21 -0600
From: brian d foy <comdog@panix.com>
Subject: Re: Creating a Perl app.  Help with installation?
Message-Id: <comdog-E72487.03332125112001@news.panix.com>

In article <9tp96s$unh$1@dipsy.missouri.edu>, 
<mcnuttj@dnps-linux1.telecom.missouri.edu> wrote:

> I've already found this to be extremely useful:
> 
> find . -type f | stripleadingdotslash - | sort > MANIFEST

of course, `make manifest` gets you there quicker, especially
since you can use MANIFEST.SKIP to exclude files that shouldn't
be in MANIFEST.

-- 
brian d foy <comdog@panix.com> - Perl services for hire
CGI Meta FAQ - http://www.perl.org/CGI_MetaFAQ.html
Troubleshooting CGI scripts - http://www.perl.org/troubleshooting_CGI.html



------------------------------

Date: Sun, 25 Nov 2001 10:07:10 +0100
From: "J. op den Brouw" <J.E.J.opdenBrouw@st.hhs.nl>
Subject: Re: File locking question
Message-Id: <3C00B4BE.23589ED5@st.hhs.nl>

Mark Jason Dominus wrote:

> It doesn't matter, since none of the data blocks are affected.  On a
> unix system, the file is identified with the inode, not with the
> name.  An open file descriptor has a pointer to the inode, not to the
> file name.  If you open a file under a certain name, say A, the
> filehandle now contains the i-number, say 123456.  Now if A is renamed
> to B, it is still inode 123456, and any writing to the filehandle will
> go into the same place as if the file had not been renamed.  The name
> is only a way of looking up the number.

And I thought I had enough Unix experience after 10 years.....

--Jesse


------------------------------

Date: Sun, 25 Nov 2001 03:44:38 -0600
From: "Jason Gray" <perl@cableone.net>
Subject: Re: file locking.
Message-Id: <u01fd6lqvc3se1@corp.supernews.com>

Nathan,
  Go to the url,
http://forums.perlguru.com/showthreaded.pl?Cat=&Board=Forum2&Number=13022&Se
arch=true&Forum=All_Forums&Words=file%20locking&Match=Entire%20Phrase&Search
page=0&Limit=25&Old=allposts&Main=13017

Regards,
Jason Gray

"Just Another Perl Programmer"




------------------------------

Date: 25 Nov 2001 04:35:28 -0800
From: merlyn@stonehenge.com (Randal L. Schwartz)
Subject: Re: Newbie OO/Inheritance question
Message-Id: <m18zcvm3jj.fsf@halfdome.holdit.com>

>>>>> "Garry" == Garry Williams <garry@ifr.zvolve.net> writes:

Garry>   use vars '@ISA';
Garry>   use Ticket;
Garry>   @ISA = ('Ticket');

Replace those with

   use base qw(Ticket);

and save yourself both some time and some brainspace...

print "Just another Perl hacker,"

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!


------------------------------

Date: 25 Nov 2001 02:16:30 -0800
From: train2venus@hotmail.com (venus)
Subject: pack
Message-Id: <bce84cea.0111250216.6c6d9290@posting.google.com>

Hi...

I have questions on pack...

1) How do I pack a number that consists of three digits? e.g. 843
Is this command able to do it? --> $buffer = pack('S',$VALUE);
where $VALUE is equal to 843...

2) Can I pack numbers which contain floating points...e.g. 34.5 or 23.5
If yes, which template should I use in place of 'S'?


Many thanks and regards.


------------------------------

Date: 25 Nov 2001 06:49:16 -0500
From: Mona Wuerz <wuerz@yahoo.com>
Subject: Re: pack
Message-Id: <m3vgfz9ikj.fsf@DCCMBX01.njitdm.campus.njit.edu>

train2venus@hotmail.com (venus) writes:

> 1) How do I pack a number that consists of three digits? e.g. 843
> Is this command able to do it? --> $buffer = pack('S',$VALUE);
> where $VALUE is equal to 843...

How about trying it out?

> 2) Can I pack numbers which contain floating points...e.g. 34.5 or 23.5
> If yes, which template should I use in place of 'S'?

How about reading the documentation for pack? (A good habit to develop
if you're into that instant response kind of thing, btw.)

perldoc -f pack
        ...
        f   A single-precision float in the native format.
        ...

-- 
$_="\n,rekcah egnufeB rehtona tsuJ";#v1<?>g\:pv-<5<
s s\S+(?:B)sunpack'u',q q$;')E4qsee;#>60#^<(v!<)g6<
print scalar reverse,$@ unless m,[+;#]55,;m:_,:#^1<


------------------------------

Date: 25 Nov 2001 00:53:46 -0800
From: jeff_nokes@yahoo.com (Jeff Nokes)
Subject: Re: Using TCP "keep alives" with IO::Socket
Message-Id: <245ee887.0111250053.3fed478a@posting.google.com>

"Real" <real@earthling.net> wrote in message news:<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.


Thanks for the information Real.  I would have posted a "thank you"
message earlier but the news server I was using just went to read
only, I had to get another.  Anyway, I appreciate your quick response
and your information helps me trememdously.

Regards,
 - Jeff


------------------------------

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 2201
***************************************


home help back first fref pref prev next nref lref last post