← Back to branch summary

~ubuntu-branches/ubuntu/raring/libanyevent-perl/raring

« back to all changes in this revision

Viewing changes to lib/AnyEvent/Handle.pm

  • Committer: Bazaar Package Importer
  • Author(s): Nicholas Bamber
  • Date: 2011-01-24 23:33:01 UTC
  • mfrom: (1.4.7 upstream)
  • Revision ID: james.westby@ubuntu.com-20110124233301-y9o4717ugdkizc2v
Tags: 5.310-1
* New upstream release
* Email change: Ansgar Burchardt -> ansgar@debian.org
* Email change: gregor herrmann -> gregoa@debian.org
* Email change: Jonathan Yu -> jawnsy@cpan.org
* Refreshed copyright using local version of dh-make-perl (cf. #609409)

Show diffs side-by-side

added added

removed removed

Lines of Context:
lib/AnyEvent/Handle.pm
767
767
   $_[0]{rbuf_max} = $_[1];
768
768
}
769
769
 
770
 
sub rbuf_max {
 
770
sub wbuf_max {
771
771
   $_[0]{wbuf_max} = $_[1];
772
772
}
773
773
 
1089
1089
C<low_water_mark> to C<0>). This method is a shorthand for just that, and
1090
1090
replaces the C<on_drain> callback with:
1091
1091
 
1092
 
   sub { shutdown $_[0]{fh}, 1 }    # for push_shutdown
 
1092
   sub { shutdown $_[0]{fh}, 1 }
1093
1093
 
1094
1094
This simply shuts down the write side and signals an EOF condition to the
1095
1095
the peer.
1775
1775
will automatically C<stop_read> for you when neither C<on_read> is set nor
1776
1776
there are any read requests in the queue.
1777
1777
 
1778
 
These methods will have no effect when in TLS mode (as TLS doesn't support
1779
 
half-duplex connections).
 
1778
In older versions of this module (<= 5.3), these methods had no effect,
 
1779
as TLS does not support half-duplex connections. In current versions they
 
1780
work as expected, as this behaviour is required to avoid certain resource
 
1781
attacks, where the program would be forced to read (and buffer) arbitrary
 
1782
amounts of data before being able to send some data. The drawback is that
 
1783
some readings of the the SSL/TLS specifications basically require this
 
1784
attack to be working, as SSL/TLS implementations might stall sending data
 
1785
during a rehandshake.
 
1786
 
 
1787
As a guideline, during the initial handshake, you should not stop reading,
 
1788
and as a client, it might cause problems, depending on your applciation.
1780
1789
 
1781
1790
=cut
1782
1791
 
1783
1792
sub stop_read {
1784
1793
   my ($self) = @_;
1785
1794
 
1786
 
   delete $self->{_rw} unless $self->{tls};
 
1795
   delete $self->{_rw};
1787
1796
}
1788
1797
 
1789
1798
sub start_read {
2043
2052
   delete @$self{qw(_rbio _wbio _tls_wbuf _on_starttls)};
2044
2053
}
2045
2054
 
 
2055
=item $handle->resettls
 
2056
 
 
2057
This rarely-used method simply resets and TLS state on the handle, usually
 
2058
causing data loss.
 
2059
 
 
2060
One case where it may be useful is when you want to skip over the data in
 
2061
the stream but you are not interested in interpreting it, so data loss is
 
2062
no concern.
 
2063
 
 
2064
=cut
 
2065
 
 
2066
*resettls = \&_freetls;
 
2067
 
2046
2068
sub DESTROY {
2047
2069
   my ($self) = @_;
2048
2070