… | |
… | |
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.331; |
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>. |
… | |
… | |
255 | You can also provide your own TLS connection object, but you have |
255 | 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> |
256 | 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 |
257 | or C<Net::SSLeay::set_accept_state> on it before you pass it to |
258 | AnyEvent::Handle. |
258 | AnyEvent::Handle. |
259 | |
259 | |
|
|
260 | B<IMPORTANT:> since Net::SSLeay "objects" are really only integers, |
|
|
261 | passing in the wrong integer will lead to certain crash. This most often |
|
|
262 | happens when one uses a stylish C<< tls => 1 >> and is surprised about the |
|
|
263 | segmentation fault. |
|
|
264 | |
260 | See the C<< ->starttls >> method for when need to start TLS negotiation later. |
265 | See the C<< ->starttls >> method for when need to start TLS negotiation later. |
261 | |
266 | |
262 | =item tls_ctx => $ssl_ctx |
267 | =item tls_ctx => $ssl_ctx |
263 | |
268 | |
264 | Use the given C<Net::SSLeay::CTX> object to create the new TLS connection |
269 | Use the given C<Net::SSLeay::CTX> object to create the new TLS connection |
… | |
… | |
374 | } |
379 | } |
375 | |
380 | |
376 | =item $handle->autocork ($boolean) |
381 | =item $handle->autocork ($boolean) |
377 | |
382 | |
378 | Enables or disables the current autocork behaviour (see C<autocork> |
383 | Enables or disables the current autocork behaviour (see C<autocork> |
379 | constructor argument). |
384 | constructor argument). Changes will only take effect on the next write. |
380 | |
385 | |
381 | =cut |
386 | =cut |
|
|
387 | |
|
|
388 | sub autocork { |
|
|
389 | $_[0]{autocork} = $_[1]; |
|
|
390 | } |
382 | |
391 | |
383 | =item $handle->no_delay ($boolean) |
392 | =item $handle->no_delay ($boolean) |
384 | |
393 | |
385 | Enables or disables the C<no_delay> setting (see constructor argument of |
394 | Enables or disables the C<no_delay> setting (see constructor argument of |
386 | the same name for details). |
395 | the same name for details). |
… | |
… | |
1371 | sub starttls { |
1380 | sub starttls { |
1372 | my ($self, $ssl, $ctx) = @_; |
1381 | my ($self, $ssl, $ctx) = @_; |
1373 | |
1382 | |
1374 | require Net::SSLeay; |
1383 | require Net::SSLeay; |
1375 | |
1384 | |
1376 | Carp::croak "it is an error to call starttls more than once on an Anyevent::Handle object" |
1385 | Carp::croak "it is an error to call starttls more than once on an AnyEvent::Handle object" |
1377 | if $self->{tls}; |
1386 | if $self->{tls}; |
1378 | |
1387 | |
1379 | if ($ssl eq "accept") { |
1388 | if ($ssl eq "accept") { |
1380 | $ssl = Net::SSLeay::new ($ctx || TLS_CTX ()); |
1389 | $ssl = Net::SSLeay::new ($ctx || TLS_CTX ()); |
1381 | Net::SSLeay::set_accept_state ($ssl); |
1390 | Net::SSLeay::set_accept_state ($ssl); |
… | |
… | |
1472 | } |
1481 | } |
1473 | } |
1482 | } |
1474 | |
1483 | |
1475 | =item $handle->destroy |
1484 | =item $handle->destroy |
1476 | |
1485 | |
1477 | Shut's down the handle object as much as possible - this call ensures that |
1486 | 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 |
1487 | 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. |
1488 | as possible. You must not call any methods on the object afterwards. |
|
|
1489 | |
|
|
1490 | Normally, you can just "forget" any references to an AnyEvent::Handle |
|
|
1491 | object and it will simply shut down. This works in fatal error and EOF |
|
|
1492 | callbacks, as well as code outside. It does I<NOT> work in a read or write |
|
|
1493 | callback, so when you want to destroy the AnyEvent::Handle object from |
|
|
1494 | within such an callback. You I<MUST> call C<< ->destroy >> explicitly in |
|
|
1495 | that case. |
1480 | |
1496 | |
1481 | The handle might still linger in the background and write out remaining |
1497 | The handle might still linger in the background and write out remaining |
1482 | data, as specified by the C<linger> option, however. |
1498 | data, as specified by the C<linger> option, however. |
1483 | |
1499 | |
1484 | =cut |
1500 | =cut |
… | |
… | |
1529 | |
1545 | |
1530 | |
1546 | |
1531 | =head1 NONFREQUENTLY ASKED QUESTIONS |
1547 | =head1 NONFREQUENTLY ASKED QUESTIONS |
1532 | |
1548 | |
1533 | =over 4 |
1549 | =over 4 |
|
|
1550 | |
|
|
1551 | =item I C<undef> the AnyEvent::Handle reference inside my callback and |
|
|
1552 | still get further invocations! |
|
|
1553 | |
|
|
1554 | That's because AnyEvent::Handle keeps a reference to itself when handling |
|
|
1555 | read or write callbacks. |
|
|
1556 | |
|
|
1557 | It is only safe to "forget" the reference inside EOF or error callbacks, |
|
|
1558 | from within all other callbacks, you need to explicitly call the C<< |
|
|
1559 | ->destroy >> method. |
|
|
1560 | |
|
|
1561 | =item I get different callback invocations in TLS mode/Why can't I pause |
|
|
1562 | reading? |
|
|
1563 | |
|
|
1564 | Unlike, say, TCP, TLS connections do not consist of two independent |
|
|
1565 | communication channels, one for each direction. Or put differently. The |
|
|
1566 | read and write directions are not independent of each other: you cannot |
|
|
1567 | write data unless you are also prepared to read, and vice versa. |
|
|
1568 | |
|
|
1569 | This can mean than, in TLS mode, you might get C<on_error> or C<on_eof> |
|
|
1570 | callback invocations when you are not expecting any read data - the reason |
|
|
1571 | is that AnyEvent::Handle always reads in TLS mode. |
|
|
1572 | |
|
|
1573 | During the connection, you have to make sure that you always have a |
|
|
1574 | non-empty read-queue, or an C<on_read> watcher. At the end of the |
|
|
1575 | connection (or when you no longer want to use it) you can call the |
|
|
1576 | C<destroy> method. |
1534 | |
1577 | |
1535 | =item How do I read data until the other side closes the connection? |
1578 | =item How do I read data until the other side closes the connection? |
1536 | |
1579 | |
1537 | If you just want to read your data into a perl scalar, the easiest way |
1580 | 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, |
1581 | to achieve this is by setting an C<on_read> callback that does nothing, |
… | |
… | |
1548 | |
1591 | |
1549 | The reason to use C<on_error> is that TCP connections, due to latencies |
1592 | 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 |
1593 | and packets loss, might get closed quite violently with an error, when in |
1551 | fact, all data has been received. |
1594 | fact, all data has been received. |
1552 | |
1595 | |
1553 | It is usually better to use acknowledgements when transfering data, |
1596 | 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 |
1597 | 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 |
1598 | intact. This is also one reason why so many internet protocols have an |
1556 | explicit QUIT command. |
1599 | explicit QUIT command. |
1557 | |
|
|
1558 | |
1600 | |
1559 | =item I don't want to destroy the handle too early - how do I wait until |
1601 | =item I don't want to destroy the handle too early - how do I wait until |
1560 | all data has been written? |
1602 | all data has been written? |
1561 | |
1603 | |
1562 | After writing your last bits of data, set the C<on_drain> callback |
1604 | After writing your last bits of data, set the C<on_drain> callback |
… | |
… | |
1568 | $handle->on_drain (sub { |
1610 | $handle->on_drain (sub { |
1569 | warn "all data submitted to the kernel\n"; |
1611 | warn "all data submitted to the kernel\n"; |
1570 | undef $handle; |
1612 | undef $handle; |
1571 | }); |
1613 | }); |
1572 | |
1614 | |
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 |
1615 | =back |
1591 | |
1616 | |
1592 | |
1617 | |
1593 | =head1 SUBCLASSING AnyEvent::Handle |
1618 | =head1 SUBCLASSING AnyEvent::Handle |
1594 | |
1619 | |