| … | |
… | |
| 114 | =over 4 |
114 | =over 4 |
| 115 | |
115 | |
| 116 | =item on_prepare => $cb->($handle) |
116 | =item on_prepare => $cb->($handle) |
| 117 | |
117 | |
| 118 | This (rarely used) callback is called before a new connection is |
118 | This (rarely used) callback is called before a new connection is |
| 119 | attempted, but after the file handle has been created. It could be used to |
119 | attempted, but after the file handle has been created (you can access that |
|
|
120 | file handle via C<< $handle->{fh} >>). It could be used to prepare the |
| 120 | prepare the file handle with parameters required for the actual connect |
121 | file handle with parameters required for the actual connect (as opposed to |
| 121 | (as opposed to settings that can be changed when the connection is already |
122 | settings that can be changed when the connection is already established). |
| 122 | established). |
|
|
| 123 | |
123 | |
| 124 | The return value of this callback should be the connect timeout value in |
124 | The return value of this callback should be the connect timeout value in |
| 125 | seconds (or C<0>, or C<undef>, or the empty list, to indicate that the |
125 | seconds (or C<0>, or C<undef>, or the empty list, to indicate that the |
| 126 | default timeout is to be used). |
126 | default timeout is to be used). |
| 127 | |
127 | |
| … | |
… | |
| 278 | For example, a server accepting connections from untrusted sources should |
278 | For example, a server accepting connections from untrusted sources should |
| 279 | be configured to accept only so-and-so much data that it cannot act on |
279 | be configured to accept only so-and-so much data that it cannot act on |
| 280 | (for example, when expecting a line, an attacker could send an unlimited |
280 | (for example, when expecting a line, an attacker could send an unlimited |
| 281 | amount of data without a callback ever being called as long as the line |
281 | amount of data without a callback ever being called as long as the line |
| 282 | isn't finished). |
282 | isn't finished). |
|
|
283 | |
|
|
284 | =item wbuf_max => <bytes> |
|
|
285 | |
|
|
286 | If defined, then a fatal error will be raised (with C<$!> set to C<ENOSPC>) |
|
|
287 | when the write buffer ever (strictly) exceeds this size. This is useful to |
|
|
288 | avoid some forms of denial-of-service attacks. |
|
|
289 | |
|
|
290 | Although the units of this parameter is bytes, this is the I<raw> number |
|
|
291 | of bytes not yet accepted by the kernel. This can make a difference when |
|
|
292 | you e.g. use TLS, as TLS typically makes your write data larger (but it |
|
|
293 | can also make it smaller due to compression). |
|
|
294 | |
|
|
295 | As an example of when this limit is useful, take a chat server that sends |
|
|
296 | chat messages to a client. If the client does not read those in a timely |
|
|
297 | manner then the send buffer in the server would grow unbounded. |
| 283 | |
298 | |
| 284 | =item autocork => <boolean> |
299 | =item autocork => <boolean> |
| 285 | |
300 | |
| 286 | When disabled (the default), C<push_write> will try to immediately |
301 | When disabled (the default), C<push_write> will try to immediately |
| 287 | write the data to the handle if possible. This avoids having to register |
302 | write the data to the handle if possible. This avoids having to register |
| … | |
… | |
| 521 | }); |
536 | }); |
| 522 | |
537 | |
| 523 | } else { |
538 | } else { |
| 524 | if ($self->{on_connect_error}) { |
539 | if ($self->{on_connect_error}) { |
| 525 | $self->{on_connect_error}($self, "$!"); |
540 | $self->{on_connect_error}($self, "$!"); |
| 526 | $self->destroy; |
541 | $self->destroy if $self; |
| 527 | } else { |
542 | } else { |
| 528 | $self->_error ($!, 1); |
543 | $self->_error ($!, 1); |
| 529 | } |
544 | } |
| 530 | } |
545 | } |
| 531 | }, |
546 | }, |
| 532 | sub { |
547 | sub { |
| 533 | local $self->{fh} = $_[0]; |
548 | local $self->{fh} = $_[0]; |
| 534 | |
549 | |
| 535 | $self->{on_prepare} |
550 | $self->{on_prepare} |
| 536 | ? $self->{on_prepare}->($self) |
551 | ? $self->{on_prepare}->($self) |
| 537 | : () |
552 | : () |
| 538 | } |
553 | } |
| 539 | ); |
554 | ); |
| 540 | } |
555 | } |
| 541 | |
556 | |
| … | |
… | |
| 740 | |
755 | |
| 741 | =item $handle->rbuf_max ($max_octets) |
756 | =item $handle->rbuf_max ($max_octets) |
| 742 | |
757 | |
| 743 | Configures the C<rbuf_max> setting (C<undef> disables it). |
758 | Configures the C<rbuf_max> setting (C<undef> disables it). |
| 744 | |
759 | |
|
|
760 | =item $handle->wbuf_max ($max_octets) |
|
|
761 | |
|
|
762 | Configures the C<wbuf_max> setting (C<undef> disables it). |
|
|
763 | |
| 745 | =cut |
764 | =cut |
| 746 | |
765 | |
| 747 | sub rbuf_max { |
766 | sub rbuf_max { |
| 748 | $_[0]{rbuf_max} = $_[1]; |
767 | $_[0]{rbuf_max} = $_[1]; |
|
|
768 | } |
|
|
769 | |
|
|
770 | sub wbuf_max { |
|
|
771 | $_[0]{wbuf_max} = $_[1]; |
| 749 | } |
772 | } |
| 750 | |
773 | |
| 751 | ############################################################################# |
774 | ############################################################################# |
| 752 | |
775 | |
| 753 | =item $handle->timeout ($seconds) |
776 | =item $handle->timeout ($seconds) |
| … | |
… | |
| 873 | if $cb && $self->{low_water_mark} >= (length $self->{wbuf}) + (length $self->{_tls_wbuf}); |
896 | if $cb && $self->{low_water_mark} >= (length $self->{wbuf}) + (length $self->{_tls_wbuf}); |
| 874 | } |
897 | } |
| 875 | |
898 | |
| 876 | =item $handle->push_write ($data) |
899 | =item $handle->push_write ($data) |
| 877 | |
900 | |
| 878 | Queues the given scalar to be written. You can push as much data as you |
901 | Queues the given scalar to be written. You can push as much data as |
| 879 | want (only limited by the available memory), as C<AnyEvent::Handle> |
902 | you want (only limited by the available memory and C<wbuf_max>), as |
| 880 | buffers it independently of the kernel. |
903 | C<AnyEvent::Handle> buffers it independently of the kernel. |
| 881 | |
904 | |
| 882 | This method may invoke callbacks (and therefore the handle might be |
905 | This method may invoke callbacks (and therefore the handle might be |
| 883 | destroyed after it returns). |
906 | destroyed after it returns). |
| 884 | |
907 | |
| 885 | =cut |
908 | =cut |
| … | |
… | |
| 913 | $cb->() unless $self->{autocork}; |
936 | $cb->() unless $self->{autocork}; |
| 914 | |
937 | |
| 915 | # if still data left in wbuf, we need to poll |
938 | # if still data left in wbuf, we need to poll |
| 916 | $self->{_ww} = AE::io $self->{fh}, 1, $cb |
939 | $self->{_ww} = AE::io $self->{fh}, 1, $cb |
| 917 | if length $self->{wbuf}; |
940 | if length $self->{wbuf}; |
|
|
941 | |
|
|
942 | if ( |
|
|
943 | defined $self->{wbuf_max} |
|
|
944 | && $self->{wbuf_max} < length $self->{wbuf} |
|
|
945 | ) { |
|
|
946 | $self->_error (Errno::ENOSPC, 1), return; |
|
|
947 | } |
| 918 | }; |
948 | }; |
| 919 | } |
949 | } |
| 920 | |
950 | |
| 921 | our %WH; |
951 | our %WH; |
| 922 | |
952 | |
| … | |
… | |
| 1057 | before it was actually written. One way to do that is to replace your |
1087 | before it was actually written. One way to do that is to replace your |
| 1058 | C<on_drain> handler by a callback that shuts down the socket (and set |
1088 | C<on_drain> handler by a callback that shuts down the socket (and set |
| 1059 | C<low_water_mark> to C<0>). This method is a shorthand for just that, and |
1089 | C<low_water_mark> to C<0>). This method is a shorthand for just that, and |
| 1060 | replaces the C<on_drain> callback with: |
1090 | replaces the C<on_drain> callback with: |
| 1061 | |
1091 | |
| 1062 | sub { shutdown $_[0]{fh}, 1 } # for push_shutdown |
1092 | sub { shutdown $_[0]{fh}, 1 } |
| 1063 | |
1093 | |
| 1064 | This simply shuts down the write side and signals an EOF condition to the |
1094 | This simply shuts down the write side and signals an EOF condition to the |
| 1065 | the peer. |
1095 | the peer. |
| 1066 | |
1096 | |
| 1067 | You can rely on the normal read queue and C<on_eof> handling |
1097 | You can rely on the normal read queue and C<on_eof> handling |
| … | |
… | |
| 1743 | Note that AnyEvent::Handle will automatically C<start_read> for you when |
1773 | Note that AnyEvent::Handle will automatically C<start_read> for you when |
| 1744 | you change the C<on_read> callback or push/unshift a read callback, and it |
1774 | you change the C<on_read> callback or push/unshift a read callback, and it |
| 1745 | will automatically C<stop_read> for you when neither C<on_read> is set nor |
1775 | will automatically C<stop_read> for you when neither C<on_read> is set nor |
| 1746 | there are any read requests in the queue. |
1776 | there are any read requests in the queue. |
| 1747 | |
1777 | |
| 1748 | These methods will have no effect when in TLS mode (as TLS doesn't support |
1778 | In older versions of this module (<= 5.3), these methods had no effect, |
| 1749 | half-duplex connections). |
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. |
| 1750 | |
1789 | |
| 1751 | =cut |
1790 | =cut |
| 1752 | |
1791 | |
| 1753 | sub stop_read { |
1792 | sub stop_read { |
| 1754 | my ($self) = @_; |
1793 | my ($self) = @_; |
| 1755 | |
1794 | |
| 1756 | delete $self->{_rw} unless $self->{tls}; |
1795 | delete $self->{_rw}; |
| 1757 | } |
1796 | } |
| 1758 | |
1797 | |
| 1759 | sub start_read { |
1798 | sub start_read { |
| 1760 | my ($self) = @_; |
1799 | my ($self) = @_; |
| 1761 | |
1800 | |
| … | |
… | |
| 2011 | if $self->{tls} > 0; |
2050 | if $self->{tls} > 0; |
| 2012 | |
2051 | |
| 2013 | delete @$self{qw(_rbio _wbio _tls_wbuf _on_starttls)}; |
2052 | delete @$self{qw(_rbio _wbio _tls_wbuf _on_starttls)}; |
| 2014 | } |
2053 | } |
| 2015 | |
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 | |
| 2016 | sub DESTROY { |
2068 | sub DESTROY { |
| 2017 | my ($self) = @_; |
2069 | my ($self) = @_; |
| 2018 | |
2070 | |
| 2019 | &_freetls; |
2071 | &_freetls; |
| 2020 | |
2072 | |
| … | |
… | |
| 2135 | |
2187 | |
| 2136 | It is only safe to "forget" the reference inside EOF or error callbacks, |
2188 | It is only safe to "forget" the reference inside EOF or error callbacks, |
| 2137 | from within all other callbacks, you need to explicitly call the C<< |
2189 | from within all other callbacks, you need to explicitly call the C<< |
| 2138 | ->destroy >> method. |
2190 | ->destroy >> method. |
| 2139 | |
2191 | |
|
|
2192 | =item Why is my C<on_eof> callback never called? |
|
|
2193 | |
|
|
2194 | Probably because your C<on_error> callback is being called instead: When |
|
|
2195 | you have outstanding requests in your read queue, then an EOF is |
|
|
2196 | considered an error as you clearly expected some data. |
|
|
2197 | |
|
|
2198 | To avoid this, make sure you have an empty read queue whenever your handle |
|
|
2199 | is supposed to be "idle" (i.e. connection closes are O.K.). You cna set |
|
|
2200 | an C<on_read> handler that simply pushes the first read requests in the |
|
|
2201 | queue. |
|
|
2202 | |
|
|
2203 | See also the next question, which explains this in a bit more detail. |
|
|
2204 | |
|
|
2205 | =item How can I serve requests in a loop? |
|
|
2206 | |
|
|
2207 | Most protocols consist of some setup phase (authentication for example) |
|
|
2208 | followed by a request handling phase, where the server waits for requests |
|
|
2209 | and handles them, in a loop. |
|
|
2210 | |
|
|
2211 | There are two important variants: The first (traditional, better) variant |
|
|
2212 | handles requests until the server gets some QUIT command, causing it to |
|
|
2213 | close the connection first (highly desirable for a busy TCP server). A |
|
|
2214 | client dropping the connection is an error, which means this variant can |
|
|
2215 | detect an unexpected detection close. |
|
|
2216 | |
|
|
2217 | To handle this case, always make sure you have a on-empty read queue, by |
|
|
2218 | pushing the "read request start" handler on it: |
|
|
2219 | |
|
|
2220 | # we assume a request starts with a single line |
|
|
2221 | my @start_request; @start_request = (line => sub { |
|
|
2222 | my ($hdl, $line) = @_; |
|
|
2223 | |
|
|
2224 | ... handle request |
|
|
2225 | |
|
|
2226 | # push next request read, possibly from a nested callback |
|
|
2227 | $hdl->push_read (@start_request); |
|
|
2228 | }); |
|
|
2229 | |
|
|
2230 | # auth done, now go into request handling loop |
|
|
2231 | # now push the first @start_request |
|
|
2232 | $hdl->push_read (@start_request); |
|
|
2233 | |
|
|
2234 | By always having an outstanding C<push_read>, the handle always expects |
|
|
2235 | some data and raises the C<EPIPE> error when the connction is dropped |
|
|
2236 | unexpectedly. |
|
|
2237 | |
|
|
2238 | The second variant is a protocol where the client can drop the connection |
|
|
2239 | at any time. For TCP, this means that the server machine may run out of |
|
|
2240 | sockets easier, and in general, it means you cnanot distinguish a protocl |
|
|
2241 | failure/client crash from a normal connection close. Nevertheless, these |
|
|
2242 | kinds of protocols are common (and sometimes even the best solution to the |
|
|
2243 | problem). |
|
|
2244 | |
|
|
2245 | Having an outstanding read request at all times is possible if you ignore |
|
|
2246 | C<EPIPE> errors, but this doesn't help with when the client drops the |
|
|
2247 | connection during a request, which would still be an error. |
|
|
2248 | |
|
|
2249 | A better solution is to push the initial request read in an C<on_read> |
|
|
2250 | callback. This avoids an error, as when the server doesn't expect data |
|
|
2251 | (i.e. is idly waiting for the next request, an EOF will not raise an |
|
|
2252 | error, but simply result in an C<on_eof> callback. It is also a bit slower |
|
|
2253 | and simpler: |
|
|
2254 | |
|
|
2255 | # auth done, now go into request handling loop |
|
|
2256 | $hdl->on_read (sub { |
|
|
2257 | my ($hdl) = @_; |
|
|
2258 | |
|
|
2259 | # called each time we receive data but the read queue is empty |
|
|
2260 | # simply start read the request |
|
|
2261 | |
|
|
2262 | $hdl->push_read (line => sub { |
|
|
2263 | my ($hdl, $line) = @_; |
|
|
2264 | |
|
|
2265 | ... handle request |
|
|
2266 | |
|
|
2267 | # do nothing special when the request has been handled, just |
|
|
2268 | # let the request queue go empty. |
|
|
2269 | }); |
|
|
2270 | }); |
|
|
2271 | |
| 2140 | =item I get different callback invocations in TLS mode/Why can't I pause |
2272 | =item I get different callback invocations in TLS mode/Why can't I pause |
| 2141 | reading? |
2273 | reading? |
| 2142 | |
2274 | |
| 2143 | Unlike, say, TCP, TLS connections do not consist of two independent |
2275 | Unlike, say, TCP, TLS connections do not consist of two independent |
| 2144 | communication channels, one for each direction. Or put differently, the |
2276 | communication channels, one for each direction. Or put differently, the |
