… | |
… | |
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 | |
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. |
|
|
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 |
288 | a write watcher and wait for the next event loop iteration, but can |
303 | a write watcher and wait for the next event loop iteration, but can |
… | |
… | |
422 | Use the C<< ->starttls >> method if you need to start TLS negotiation later. |
437 | Use the C<< ->starttls >> method if you need to start TLS negotiation later. |
423 | |
438 | |
424 | =item tls_ctx => $anyevent_tls |
439 | =item tls_ctx => $anyevent_tls |
425 | |
440 | |
426 | Use the given C<AnyEvent::TLS> object to create the new TLS connection |
441 | Use the given C<AnyEvent::TLS> object to create the new TLS connection |
427 | (unless a connection object was specified directly). If this parameter is |
442 | (unless a connection object was specified directly). If this |
428 | missing, then AnyEvent::Handle will use C<AnyEvent::Handle::TLS_CTX>. |
443 | parameter is missing (or C<undef>), then AnyEvent::Handle will use |
|
|
444 | C<AnyEvent::Handle::TLS_CTX>. |
429 | |
445 | |
430 | Instead of an object, you can also specify a hash reference with C<< key |
446 | Instead of an object, you can also specify a hash reference with C<< key |
431 | => value >> pairs. Those will be passed to L<AnyEvent::TLS> to create a |
447 | => value >> pairs. Those will be passed to L<AnyEvent::TLS> to create a |
432 | new TLS context object. |
448 | new TLS context object. |
433 | |
449 | |
… | |
… | |
739 | |
755 | |
740 | =item $handle->rbuf_max ($max_octets) |
756 | =item $handle->rbuf_max ($max_octets) |
741 | |
757 | |
742 | Configures the C<rbuf_max> setting (C<undef> disables it). |
758 | Configures the C<rbuf_max> setting (C<undef> disables it). |
743 | |
759 | |
|
|
760 | =item $handle->wbuf_max ($max_octets) |
|
|
761 | |
|
|
762 | Configures the C<wbuf_max> setting (C<undef> disables it). |
|
|
763 | |
744 | =cut |
764 | =cut |
745 | |
765 | |
746 | sub rbuf_max { |
766 | sub rbuf_max { |
747 | $_[0]{rbuf_max} = $_[1]; |
767 | $_[0]{rbuf_max} = $_[1]; |
|
|
768 | } |
|
|
769 | |
|
|
770 | sub rbuf_max { |
|
|
771 | $_[0]{wbuf_max} = $_[1]; |
748 | } |
772 | } |
749 | |
773 | |
750 | ############################################################################# |
774 | ############################################################################# |
751 | |
775 | |
752 | =item $handle->timeout ($seconds) |
776 | =item $handle->timeout ($seconds) |
… | |
… | |
872 | 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}); |
873 | } |
897 | } |
874 | |
898 | |
875 | =item $handle->push_write ($data) |
899 | =item $handle->push_write ($data) |
876 | |
900 | |
877 | 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 |
878 | 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 |
879 | buffers it independently of the kernel. |
903 | C<AnyEvent::Handle> buffers it independently of the kernel. |
880 | |
904 | |
881 | This method may invoke callbacks (and therefore the handle might be |
905 | This method may invoke callbacks (and therefore the handle might be |
882 | destroyed after it returns). |
906 | destroyed after it returns). |
883 | |
907 | |
884 | =cut |
908 | =cut |
… | |
… | |
912 | $cb->() unless $self->{autocork}; |
936 | $cb->() unless $self->{autocork}; |
913 | |
937 | |
914 | # if still data left in wbuf, we need to poll |
938 | # if still data left in wbuf, we need to poll |
915 | $self->{_ww} = AE::io $self->{fh}, 1, $cb |
939 | $self->{_ww} = AE::io $self->{fh}, 1, $cb |
916 | 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 | } |
917 | }; |
948 | }; |
918 | } |
949 | } |
919 | |
950 | |
920 | our %WH; |
951 | our %WH; |
921 | |
952 | |
… | |
… | |
2134 | |
2165 | |
2135 | It is only safe to "forget" the reference inside EOF or error callbacks, |
2166 | It is only safe to "forget" the reference inside EOF or error callbacks, |
2136 | from within all other callbacks, you need to explicitly call the C<< |
2167 | from within all other callbacks, you need to explicitly call the C<< |
2137 | ->destroy >> method. |
2168 | ->destroy >> method. |
2138 | |
2169 | |
|
|
2170 | =item Why is my C<on_eof> callback never called? |
|
|
2171 | |
|
|
2172 | Probably because your C<on_error> callback is being called instead: When |
|
|
2173 | you have outstanding requests in your read queue, then an EOF is |
|
|
2174 | considered an error as you clearly expected some data. |
|
|
2175 | |
|
|
2176 | To avoid this, make sure you have an empty read queue whenever your handle |
|
|
2177 | is supposed to be "idle" (i.e. connection closes are O.K.). You cna set |
|
|
2178 | an C<on_read> handler that simply pushes the first read requests in the |
|
|
2179 | queue. |
|
|
2180 | |
|
|
2181 | See also the next question, which explains this in a bit more detail. |
|
|
2182 | |
|
|
2183 | =item How can I serve requests in a loop? |
|
|
2184 | |
|
|
2185 | Most protocols consist of some setup phase (authentication for example) |
|
|
2186 | followed by a request handling phase, where the server waits for requests |
|
|
2187 | and handles them, in a loop. |
|
|
2188 | |
|
|
2189 | There are two important variants: The first (traditional, better) variant |
|
|
2190 | handles requests until the server gets some QUIT command, causing it to |
|
|
2191 | close the connection first (highly desirable for a busy TCP server). A |
|
|
2192 | client dropping the connection is an error, which means this variant can |
|
|
2193 | detect an unexpected detection close. |
|
|
2194 | |
|
|
2195 | To handle this case, always make sure you have a on-empty read queue, by |
|
|
2196 | pushing the "read request start" handler on it: |
|
|
2197 | |
|
|
2198 | # we assume a request starts with a single line |
|
|
2199 | my @start_request; @start_request = (line => sub { |
|
|
2200 | my ($hdl, $line) = @_; |
|
|
2201 | |
|
|
2202 | ... handle request |
|
|
2203 | |
|
|
2204 | # push next request read, possibly from a nested callback |
|
|
2205 | $hdl->push_read (@start_request); |
|
|
2206 | }); |
|
|
2207 | |
|
|
2208 | # auth done, now go into request handling loop |
|
|
2209 | # now push the first @start_request |
|
|
2210 | $hdl->push_read (@start_request); |
|
|
2211 | |
|
|
2212 | By always having an outstanding C<push_read>, the handle always expects |
|
|
2213 | some data and raises the C<EPIPE> error when the connction is dropped |
|
|
2214 | unexpectedly. |
|
|
2215 | |
|
|
2216 | The second variant is a protocol where the client can drop the connection |
|
|
2217 | at any time. For TCP, this means that the server machine may run out of |
|
|
2218 | sockets easier, and in general, it means you cnanot distinguish a protocl |
|
|
2219 | failure/client crash from a normal connection close. Nevertheless, these |
|
|
2220 | kinds of protocols are common (and sometimes even the best solution to the |
|
|
2221 | problem). |
|
|
2222 | |
|
|
2223 | Having an outstanding read request at all times is possible if you ignore |
|
|
2224 | C<EPIPE> errors, but this doesn't help with when the client drops the |
|
|
2225 | connection during a request, which would still be an error. |
|
|
2226 | |
|
|
2227 | A better solution is to push the initial request read in an C<on_read> |
|
|
2228 | callback. This avoids an error, as when the server doesn't expect data |
|
|
2229 | (i.e. is idly waiting for the next request, an EOF will not raise an |
|
|
2230 | error, but simply result in an C<on_eof> callback. It is also a bit slower |
|
|
2231 | and simpler: |
|
|
2232 | |
|
|
2233 | # auth done, now go into request handling loop |
|
|
2234 | $hdl->on_read (sub { |
|
|
2235 | my ($hdl) = @_; |
|
|
2236 | |
|
|
2237 | # called each time we receive data but the read queue is empty |
|
|
2238 | # simply start read the request |
|
|
2239 | |
|
|
2240 | $hdl->push_read (line => sub { |
|
|
2241 | my ($hdl, $line) = @_; |
|
|
2242 | |
|
|
2243 | ... handle request |
|
|
2244 | |
|
|
2245 | # do nothing special when the request has been handled, just |
|
|
2246 | # let the request queue go empty. |
|
|
2247 | }); |
|
|
2248 | }); |
|
|
2249 | |
2139 | =item I get different callback invocations in TLS mode/Why can't I pause |
2250 | =item I get different callback invocations in TLS mode/Why can't I pause |
2140 | reading? |
2251 | reading? |
2141 | |
2252 | |
2142 | Unlike, say, TCP, TLS connections do not consist of two independent |
2253 | Unlike, say, TCP, TLS connections do not consist of two independent |
2143 | communication channels, one for each direction. Or put differently, the |
2254 | communication channels, one for each direction. Or put differently, the |