… | |
… | |
14 | |
14 | |
15 | AnyEvent::Handle - non-blocking I/O on file handles via AnyEvent |
15 | AnyEvent::Handle - non-blocking I/O on file handles via AnyEvent |
16 | |
16 | |
17 | =cut |
17 | =cut |
18 | |
18 | |
19 | our $VERSION = 4.3; |
19 | our $VERSION = 4.35; |
20 | |
20 | |
21 | =head1 SYNOPSIS |
21 | =head1 SYNOPSIS |
22 | |
22 | |
23 | use AnyEvent; |
23 | use AnyEvent; |
24 | use AnyEvent::Handle; |
24 | use AnyEvent::Handle; |
… | |
… | |
27 | |
27 | |
28 | my $handle = |
28 | my $handle = |
29 | AnyEvent::Handle->new ( |
29 | AnyEvent::Handle->new ( |
30 | fh => \*STDIN, |
30 | fh => \*STDIN, |
31 | on_eof => sub { |
31 | on_eof => sub { |
32 | $cv->broadcast; |
32 | $cv->send; |
33 | }, |
33 | }, |
34 | ); |
34 | ); |
35 | |
35 | |
36 | # send some request line |
36 | # send some request line |
37 | $handle->push_write ("getinfo\015\012"); |
37 | $handle->push_write ("getinfo\015\012"); |
… | |
… | |
84 | Set the callback to be called when an end-of-file condition is detected, |
84 | Set the callback to be called when an end-of-file condition is detected, |
85 | i.e. in the case of a socket, when the other side has closed the |
85 | i.e. in the case of a socket, when the other side has closed the |
86 | connection cleanly. |
86 | connection cleanly. |
87 | |
87 | |
88 | For sockets, this just means that the other side has stopped sending data, |
88 | For sockets, this just means that the other side has stopped sending data, |
89 | you can still try to write data, and, in fact, one can return from the eof |
89 | you can still try to write data, and, in fact, one can return from the EOF |
90 | callback and continue writing data, as only the read part has been shut |
90 | callback and continue writing data, as only the read part has been shut |
91 | down. |
91 | down. |
92 | |
92 | |
93 | While not mandatory, it is I<highly> recommended to set an eof callback, |
93 | While not mandatory, it is I<highly> recommended to set an EOF callback, |
94 | otherwise you might end up with a closed socket while you are still |
94 | otherwise you might end up with a closed socket while you are still |
95 | waiting for data. |
95 | waiting for data. |
96 | |
96 | |
97 | If an EOF condition has been detected but no C<on_eof> callback has been |
97 | If an EOF condition has been detected but no C<on_eof> callback has been |
98 | set, then a fatal error will be raised with C<$!> set to <0>. |
98 | set, then a fatal error will be raised with C<$!> set to <0>. |
… | |
… | |
127 | and no read request is in the queue (unlike read queue callbacks, this |
127 | and no read request is in the queue (unlike read queue callbacks, this |
128 | callback will only be called when at least one octet of data is in the |
128 | callback will only be called when at least one octet of data is in the |
129 | read buffer). |
129 | read buffer). |
130 | |
130 | |
131 | To access (and remove data from) the read buffer, use the C<< ->rbuf >> |
131 | To access (and remove data from) the read buffer, use the C<< ->rbuf >> |
132 | method or access the C<$handle->{rbuf}> member directly. |
132 | method or access the C<$handle->{rbuf}> member directly. Note that you |
|
|
133 | must not enlarge or modify the read buffer, you can only remove data at |
|
|
134 | the beginning from it. |
133 | |
135 | |
134 | When an EOF condition is detected then AnyEvent::Handle will first try to |
136 | When an EOF condition is detected then AnyEvent::Handle will first try to |
135 | feed all the remaining data to the queued callbacks and C<on_read> before |
137 | feed all the remaining data to the queued callbacks and C<on_read> before |
136 | calling the C<on_eof> callback. If no progress can be made, then a fatal |
138 | calling the C<on_eof> callback. If no progress can be made, then a fatal |
137 | error will be raised (with C<$!> set to C<EPIPE>). |
139 | error will be raised (with C<$!> set to C<EPIPE>). |
… | |
… | |
255 | You can also provide your own TLS connection object, but you have |
257 | You can also provide your own TLS connection object, but you have |
256 | to make sure that you call either C<Net::SSLeay::set_connect_state> |
258 | to make sure that you call either C<Net::SSLeay::set_connect_state> |
257 | or C<Net::SSLeay::set_accept_state> on it before you pass it to |
259 | or C<Net::SSLeay::set_accept_state> on it before you pass it to |
258 | AnyEvent::Handle. |
260 | AnyEvent::Handle. |
259 | |
261 | |
|
|
262 | B<IMPORTANT:> since Net::SSLeay "objects" are really only integers, |
|
|
263 | passing in the wrong integer will lead to certain crash. This most often |
|
|
264 | happens when one uses a stylish C<< tls => 1 >> and is surprised about the |
|
|
265 | segmentation fault. |
|
|
266 | |
260 | See the C<< ->starttls >> method for when need to start TLS negotiation later. |
267 | See the C<< ->starttls >> method for when need to start TLS negotiation later. |
261 | |
268 | |
262 | =item tls_ctx => $ssl_ctx |
269 | =item tls_ctx => $ssl_ctx |
263 | |
270 | |
264 | Use the given C<Net::SSLeay::CTX> object to create the new TLS connection |
271 | Use the given C<Net::SSLeay::CTX> object to create the new TLS connection |
… | |
… | |
326 | |
333 | |
327 | $! = $errno; |
334 | $! = $errno; |
328 | |
335 | |
329 | if ($self->{on_error}) { |
336 | if ($self->{on_error}) { |
330 | $self->{on_error}($self, $fatal); |
337 | $self->{on_error}($self, $fatal); |
331 | } else { |
338 | } elsif ($self->{fh}) { |
332 | Carp::croak "AnyEvent::Handle uncaught error: $!"; |
339 | Carp::croak "AnyEvent::Handle uncaught error: $!"; |
333 | } |
340 | } |
334 | } |
341 | } |
335 | |
342 | |
336 | =item $fh = $handle->fh |
343 | =item $fh = $handle->fh |
… | |
… | |
374 | } |
381 | } |
375 | |
382 | |
376 | =item $handle->autocork ($boolean) |
383 | =item $handle->autocork ($boolean) |
377 | |
384 | |
378 | Enables or disables the current autocork behaviour (see C<autocork> |
385 | Enables or disables the current autocork behaviour (see C<autocork> |
379 | constructor argument). |
386 | constructor argument). Changes will only take effect on the next write. |
380 | |
387 | |
381 | =cut |
388 | =cut |
|
|
389 | |
|
|
390 | sub autocork { |
|
|
391 | $_[0]{autocork} = $_[1]; |
|
|
392 | } |
382 | |
393 | |
383 | =item $handle->no_delay ($boolean) |
394 | =item $handle->no_delay ($boolean) |
384 | |
395 | |
385 | Enables or disables the C<no_delay> setting (see constructor argument of |
396 | Enables or disables the C<no_delay> setting (see constructor argument of |
386 | the same name for details). |
397 | the same name for details). |
… | |
… | |
758 | ) { |
769 | ) { |
759 | $self->_error (&Errno::ENOSPC, 1), return; |
770 | $self->_error (&Errno::ENOSPC, 1), return; |
760 | } |
771 | } |
761 | |
772 | |
762 | while () { |
773 | while () { |
|
|
774 | # we need to use a separate tls read buffer, as we must not receive data while |
|
|
775 | # we are draining the buffer, and this can only happen with TLS. |
|
|
776 | $self->{rbuf} .= delete $self->{_tls_rbuf} if exists $self->{_tls_rbuf}; |
|
|
777 | |
763 | my $len = length $self->{rbuf}; |
778 | my $len = length $self->{rbuf}; |
764 | |
779 | |
765 | if (my $cb = shift @{ $self->{_queue} }) { |
780 | if (my $cb = shift @{ $self->{_queue} }) { |
766 | unless ($cb->($self)) { |
781 | unless ($cb->($self)) { |
767 | if ($self->{_eof}) { |
782 | if ($self->{_eof}) { |
… | |
… | |
828 | |
843 | |
829 | =item $handle->rbuf |
844 | =item $handle->rbuf |
830 | |
845 | |
831 | Returns the read buffer (as a modifiable lvalue). |
846 | Returns the read buffer (as a modifiable lvalue). |
832 | |
847 | |
833 | You can access the read buffer directly as the C<< ->{rbuf} >> member, if |
848 | You can access the read buffer directly as the C<< ->{rbuf} >> |
834 | you want. |
849 | member, if you want. However, the only operation allowed on the |
|
|
850 | read buffer (apart from looking at it) is removing data from its |
|
|
851 | beginning. Otherwise modifying or appending to it is not allowed and will |
|
|
852 | lead to hard-to-track-down bugs. |
835 | |
853 | |
836 | NOTE: The read buffer should only be used or modified if the C<on_read>, |
854 | NOTE: The read buffer should only be used or modified if the C<on_read>, |
837 | C<push_read> or C<unshift_read> methods are used. The other read methods |
855 | C<push_read> or C<unshift_read> methods are used. The other read methods |
838 | automatically manage the read buffer. |
856 | automatically manage the read buffer. |
839 | |
857 | |
… | |
… | |
1135 | } |
1153 | } |
1136 | }; |
1154 | }; |
1137 | |
1155 | |
1138 | =item json => $cb->($handle, $hash_or_arrayref) |
1156 | =item json => $cb->($handle, $hash_or_arrayref) |
1139 | |
1157 | |
1140 | Reads a JSON object or array, decodes it and passes it to the callback. |
1158 | Reads a JSON object or array, decodes it and passes it to the |
|
|
1159 | callback. When a parse error occurs, an C<EBADMSG> error will be raised. |
1141 | |
1160 | |
1142 | If a C<json> object was passed to the constructor, then that will be used |
1161 | If a C<json> object was passed to the constructor, then that will be used |
1143 | for the final decode, otherwise it will create a JSON coder expecting UTF-8. |
1162 | for the final decode, otherwise it will create a JSON coder expecting UTF-8. |
1144 | |
1163 | |
1145 | This read type uses the incremental parser available with JSON version |
1164 | This read type uses the incremental parser available with JSON version |
… | |
… | |
1162 | my $rbuf = \$self->{rbuf}; |
1181 | my $rbuf = \$self->{rbuf}; |
1163 | |
1182 | |
1164 | my $json = $self->{json} ||= JSON->new->utf8; |
1183 | my $json = $self->{json} ||= JSON->new->utf8; |
1165 | |
1184 | |
1166 | sub { |
1185 | sub { |
1167 | my $ref = $json->incr_parse ($self->{rbuf}); |
1186 | my $ref = eval { $json->incr_parse ($self->{rbuf}) }; |
1168 | |
1187 | |
1169 | if ($ref) { |
1188 | if ($ref) { |
1170 | $self->{rbuf} = $json->incr_text; |
1189 | $self->{rbuf} = $json->incr_text; |
1171 | $json->incr_text = ""; |
1190 | $json->incr_text = ""; |
1172 | $cb->($self, $ref); |
1191 | $cb->($self, $ref); |
1173 | |
1192 | |
1174 | 1 |
1193 | 1 |
|
|
1194 | } elsif ($@) { |
|
|
1195 | # error case |
|
|
1196 | $json->incr_skip; |
|
|
1197 | |
|
|
1198 | $self->{rbuf} = $json->incr_text; |
|
|
1199 | $json->incr_text = ""; |
|
|
1200 | |
|
|
1201 | $self->_error (&Errno::EBADMSG); |
|
|
1202 | |
|
|
1203 | () |
1175 | } else { |
1204 | } else { |
1176 | $self->{rbuf} = ""; |
1205 | $self->{rbuf} = ""; |
|
|
1206 | |
1177 | () |
1207 | () |
1178 | } |
1208 | } |
1179 | } |
1209 | } |
1180 | }; |
1210 | }; |
1181 | |
1211 | |
… | |
… | |
1322 | delete $self->{_rw}; |
1352 | delete $self->{_rw}; |
1323 | $self->{_eof} = 1; |
1353 | $self->{_eof} = 1; |
1324 | &_freetls; |
1354 | &_freetls; |
1325 | } |
1355 | } |
1326 | |
1356 | |
1327 | $self->{rbuf} .= $tmp; |
1357 | $self->{_tls_rbuf} .= $tmp; |
1328 | $self->_drain_rbuf unless $self->{_in_drain}; |
1358 | $self->_drain_rbuf unless $self->{_in_drain}; |
1329 | $self->{tls} or return; # tls session might have gone away in callback |
1359 | $self->{tls} or return; # tls session might have gone away in callback |
1330 | } |
1360 | } |
1331 | |
1361 | |
1332 | $tmp = Net::SSLeay::get_error ($self->{tls}, -1); |
1362 | $tmp = Net::SSLeay::get_error ($self->{tls}, -1); |
1333 | |
1363 | |
1334 | if ($tmp != Net::SSLeay::ERROR_WANT_READ ()) { |
1364 | if ($tmp != Net::SSLeay::ERROR_WANT_READ ()) { |
1335 | if ($tmp == Net::SSLeay::ERROR_SYSCALL ()) { |
1365 | if ($tmp == Net::SSLeay::ERROR_SYSCALL ()) { |
1336 | return $self->_error ($!, 1); |
1366 | return $self->_error ($!, 1); |
1337 | } elsif ($tmp == Net::SSLeay::ERROR_SSL ()) { |
1367 | } elsif ($tmp == Net::SSLeay::ERROR_SSL ()) { |
1338 | return $self->_error (&Errno::EIO, 1); |
1368 | return $self->_error (&Errno::EIO, 1); |
1339 | } |
1369 | } |
1340 | |
1370 | |
1341 | # all other errors are fine for our purposes |
1371 | # all other errors are fine for our purposes |
1342 | } |
1372 | } |
… | |
… | |
1371 | sub starttls { |
1401 | sub starttls { |
1372 | my ($self, $ssl, $ctx) = @_; |
1402 | my ($self, $ssl, $ctx) = @_; |
1373 | |
1403 | |
1374 | require Net::SSLeay; |
1404 | require Net::SSLeay; |
1375 | |
1405 | |
1376 | Carp::croak "it is an error to call starttls more than once on an Anyevent::Handle object" |
1406 | Carp::croak "it is an error to call starttls more than once on an AnyEvent::Handle object" |
1377 | if $self->{tls}; |
1407 | if $self->{tls}; |
1378 | |
1408 | |
1379 | if ($ssl eq "accept") { |
1409 | if ($ssl eq "accept") { |
1380 | $ssl = Net::SSLeay::new ($ctx || TLS_CTX ()); |
1410 | $ssl = Net::SSLeay::new ($ctx || TLS_CTX ()); |
1381 | Net::SSLeay::set_accept_state ($ssl); |
1411 | Net::SSLeay::set_accept_state ($ssl); |
… | |
… | |
1443 | |
1473 | |
1444 | delete @$self{qw(_rbio _wbio _tls_wbuf)}; |
1474 | delete @$self{qw(_rbio _wbio _tls_wbuf)}; |
1445 | } |
1475 | } |
1446 | |
1476 | |
1447 | sub DESTROY { |
1477 | sub DESTROY { |
1448 | my $self = shift; |
1478 | my ($self) = @_; |
1449 | |
1479 | |
1450 | &_freetls; |
1480 | &_freetls; |
1451 | |
1481 | |
1452 | my $linger = exists $self->{linger} ? $self->{linger} : 3600; |
1482 | my $linger = exists $self->{linger} ? $self->{linger} : 3600; |
1453 | |
1483 | |
… | |
… | |
1472 | } |
1502 | } |
1473 | } |
1503 | } |
1474 | |
1504 | |
1475 | =item $handle->destroy |
1505 | =item $handle->destroy |
1476 | |
1506 | |
1477 | Shut's down the handle object as much as possible - this call ensures that |
1507 | Shuts down the handle object as much as possible - this call ensures that |
1478 | no further callbacks will be invoked and resources will be freed as much |
1508 | no further callbacks will be invoked and resources will be freed as much |
1479 | as possible. You must not call any methods on the object afterwards. |
1509 | as possible. You must not call any methods on the object afterwards. |
|
|
1510 | |
|
|
1511 | Normally, you can just "forget" any references to an AnyEvent::Handle |
|
|
1512 | object and it will simply shut down. This works in fatal error and EOF |
|
|
1513 | callbacks, as well as code outside. It does I<NOT> work in a read or write |
|
|
1514 | callback, so when you want to destroy the AnyEvent::Handle object from |
|
|
1515 | within such an callback. You I<MUST> call C<< ->destroy >> explicitly in |
|
|
1516 | that case. |
1480 | |
1517 | |
1481 | The handle might still linger in the background and write out remaining |
1518 | The handle might still linger in the background and write out remaining |
1482 | data, as specified by the C<linger> option, however. |
1519 | data, as specified by the C<linger> option, however. |
1483 | |
1520 | |
1484 | =cut |
1521 | =cut |
… | |
… | |
1529 | |
1566 | |
1530 | |
1567 | |
1531 | =head1 NONFREQUENTLY ASKED QUESTIONS |
1568 | =head1 NONFREQUENTLY ASKED QUESTIONS |
1532 | |
1569 | |
1533 | =over 4 |
1570 | =over 4 |
|
|
1571 | |
|
|
1572 | =item I C<undef> the AnyEvent::Handle reference inside my callback and |
|
|
1573 | still get further invocations! |
|
|
1574 | |
|
|
1575 | That's because AnyEvent::Handle keeps a reference to itself when handling |
|
|
1576 | read or write callbacks. |
|
|
1577 | |
|
|
1578 | It is only safe to "forget" the reference inside EOF or error callbacks, |
|
|
1579 | from within all other callbacks, you need to explicitly call the C<< |
|
|
1580 | ->destroy >> method. |
|
|
1581 | |
|
|
1582 | =item I get different callback invocations in TLS mode/Why can't I pause |
|
|
1583 | reading? |
|
|
1584 | |
|
|
1585 | Unlike, say, TCP, TLS connections do not consist of two independent |
|
|
1586 | communication channels, one for each direction. Or put differently. The |
|
|
1587 | read and write directions are not independent of each other: you cannot |
|
|
1588 | write data unless you are also prepared to read, and vice versa. |
|
|
1589 | |
|
|
1590 | This can mean than, in TLS mode, you might get C<on_error> or C<on_eof> |
|
|
1591 | callback invocations when you are not expecting any read data - the reason |
|
|
1592 | is that AnyEvent::Handle always reads in TLS mode. |
|
|
1593 | |
|
|
1594 | During the connection, you have to make sure that you always have a |
|
|
1595 | non-empty read-queue, or an C<on_read> watcher. At the end of the |
|
|
1596 | connection (or when you no longer want to use it) you can call the |
|
|
1597 | C<destroy> method. |
1534 | |
1598 | |
1535 | =item How do I read data until the other side closes the connection? |
1599 | =item How do I read data until the other side closes the connection? |
1536 | |
1600 | |
1537 | If you just want to read your data into a perl scalar, the easiest way |
1601 | If you just want to read your data into a perl scalar, the easiest way |
1538 | to achieve this is by setting an C<on_read> callback that does nothing, |
1602 | to achieve this is by setting an C<on_read> callback that does nothing, |
… | |
… | |
1548 | |
1612 | |
1549 | The reason to use C<on_error> is that TCP connections, due to latencies |
1613 | The reason to use C<on_error> is that TCP connections, due to latencies |
1550 | and packets loss, might get closed quite violently with an error, when in |
1614 | and packets loss, might get closed quite violently with an error, when in |
1551 | fact, all data has been received. |
1615 | fact, all data has been received. |
1552 | |
1616 | |
1553 | It is usually better to use acknowledgements when transfering data, |
1617 | It is usually better to use acknowledgements when transferring data, |
1554 | to make sure the other side hasn't just died and you got the data |
1618 | to make sure the other side hasn't just died and you got the data |
1555 | intact. This is also one reason why so many internet protocols have an |
1619 | intact. This is also one reason why so many internet protocols have an |
1556 | explicit QUIT command. |
1620 | explicit QUIT command. |
1557 | |
|
|
1558 | |
1621 | |
1559 | =item I don't want to destroy the handle too early - how do I wait until |
1622 | =item I don't want to destroy the handle too early - how do I wait until |
1560 | all data has been written? |
1623 | all data has been written? |
1561 | |
1624 | |
1562 | After writing your last bits of data, set the C<on_drain> callback |
1625 | After writing your last bits of data, set the C<on_drain> callback |
… | |
… | |
1568 | $handle->on_drain (sub { |
1631 | $handle->on_drain (sub { |
1569 | warn "all data submitted to the kernel\n"; |
1632 | warn "all data submitted to the kernel\n"; |
1570 | undef $handle; |
1633 | undef $handle; |
1571 | }); |
1634 | }); |
1572 | |
1635 | |
1573 | =item I get different callback invocations in TLS mode/Why can't I pause |
|
|
1574 | reading? |
|
|
1575 | |
|
|
1576 | Unlike, say, TCP, TLS conenctions do not consist of two independent |
|
|
1577 | communication channels, one for each direction. Or put differently. the |
|
|
1578 | read and write directions are not independent of each other: you cannot |
|
|
1579 | write data unless you are also prepared to read, and vice versa. |
|
|
1580 | |
|
|
1581 | This can mean than, in TLS mode, you might get C<on_error> or C<on_eof> |
|
|
1582 | callback invocations when you are not expecting any read data - the reason |
|
|
1583 | is that AnyEvent::Handle always reads in TLS mode. |
|
|
1584 | |
|
|
1585 | During the connection, you have to make sure that you always have a |
|
|
1586 | non-empty read-queue, or an C<on_read> watcher. At the end of the |
|
|
1587 | connection (or when you no longer want to use it) you can call the |
|
|
1588 | C<destroy> method. |
|
|
1589 | |
|
|
1590 | =back |
1636 | =back |
1591 | |
1637 | |
1592 | |
1638 | |
1593 | =head1 SUBCLASSING AnyEvent::Handle |
1639 | =head1 SUBCLASSING AnyEvent::Handle |
1594 | |
1640 | |