… | |
… | |
30 | |
30 | |
31 | $cv->recv; |
31 | $cv->recv; |
32 | |
32 | |
33 | =head1 DESCRIPTION |
33 | =head1 DESCRIPTION |
34 | |
34 | |
35 | This module is a helper module to make it easier to do event-based I/O on |
35 | This is a helper module to make it easier to do event-based I/O on |
36 | stream-based filehandles (sockets, pipes or other stream things). |
36 | stream-based filehandles (sockets, pipes, and other stream things). |
37 | |
37 | |
38 | The L<AnyEvent::Intro> tutorial contains some well-documented |
38 | The L<AnyEvent::Intro> tutorial contains some well-documented |
39 | AnyEvent::Handle examples. |
39 | AnyEvent::Handle examples. |
40 | |
40 | |
41 | In the following, when the documentation refers to of "bytes" then this |
41 | In the following, where the documentation refers to "bytes", it means |
42 | means characters. As sysread and syswrite are used for all I/O, their |
42 | characters. As sysread and syswrite are used for all I/O, their |
43 | treatment of characters applies to this module as well. |
43 | treatment of characters applies to this module as well. |
44 | |
44 | |
45 | At the very minimum, you should specify C<fh> or C<connect>, and the |
45 | At the very minimum, you should specify C<fh> or C<connect>, and the |
46 | C<on_error> callback. |
46 | C<on_error> callback. |
47 | |
47 | |
… | |
… | |
118 | prepare the file handle with parameters required for the actual connect |
118 | prepare the file handle with parameters required for the actual connect |
119 | (as opposed to settings that can be changed when the connection is already |
119 | (as opposed to settings that can be changed when the connection is already |
120 | established). |
120 | established). |
121 | |
121 | |
122 | The return value of this callback should be the connect timeout value in |
122 | The return value of this callback should be the connect timeout value in |
123 | seconds (or C<0>, or C<undef>, or the empty list, to indicate the default |
123 | seconds (or C<0>, or C<undef>, or the empty list, to indicate that the |
124 | timeout is to be used). |
124 | default timeout is to be used). |
125 | |
125 | |
126 | =item on_connect => $cb->($handle, $host, $port, $retry->()) |
126 | =item on_connect => $cb->($handle, $host, $port, $retry->()) |
127 | |
127 | |
128 | This callback is called when a connection has been successfully established. |
128 | This callback is called when a connection has been successfully established. |
129 | |
129 | |
130 | The actual numeric host and port (the socket peername) are passed as |
130 | The peer's numeric host and port (the socket peername) are passed as |
131 | parameters, together with a retry callback. |
131 | parameters, together with a retry callback. |
132 | |
132 | |
133 | When, for some reason, the handle is not acceptable, then calling |
133 | If, for some reason, the handle is not acceptable, calling C<$retry> |
134 | C<$retry> will continue with the next connection target (in case of |
134 | will continue with the next connection target (in case of multi-homed |
135 | multi-homed hosts or SRV records there can be multiple connection |
135 | hosts or SRV records there can be multiple connection endpoints). At the |
136 | endpoints). At the time it is called the read and write queues, eof |
136 | time it is called the read and write queues, eof status, tls status and |
137 | status, tls status and similar properties of the handle will have been |
137 | similar properties of the handle will have been reset. |
138 | reset. |
|
|
139 | |
138 | |
140 | In most cases, ignoring the C<$retry> parameter is the way to go. |
139 | In most cases, you should ignore the C<$retry> parameter. |
141 | |
140 | |
142 | =item on_connect_error => $cb->($handle, $message) |
141 | =item on_connect_error => $cb->($handle, $message) |
143 | |
142 | |
144 | This callback is called when the connection could not be |
143 | This callback is called when the connection could not be |
145 | established. C<$!> will contain the relevant error code, and C<$message> a |
144 | established. C<$!> will contain the relevant error code, and C<$message> a |
… | |
… | |
152 | |
151 | |
153 | =item on_error => $cb->($handle, $fatal, $message) |
152 | =item on_error => $cb->($handle, $fatal, $message) |
154 | |
153 | |
155 | This is the error callback, which is called when, well, some error |
154 | This is the error callback, which is called when, well, some error |
156 | occured, such as not being able to resolve the hostname, failure to |
155 | occured, such as not being able to resolve the hostname, failure to |
157 | connect or a read error. |
156 | connect, or a read error. |
158 | |
157 | |
159 | Some errors are fatal (which is indicated by C<$fatal> being true). On |
158 | Some errors are fatal (which is indicated by C<$fatal> being true). On |
160 | fatal errors the handle object will be destroyed (by a call to C<< -> |
159 | fatal errors the handle object will be destroyed (by a call to C<< -> |
161 | destroy >>) after invoking the error callback (which means you are free to |
160 | destroy >>) after invoking the error callback (which means you are free to |
162 | examine the handle object). Examples of fatal errors are an EOF condition |
161 | examine the handle object). Examples of fatal errors are an EOF condition |
163 | with active (but unsatisifable) read watchers (C<EPIPE>) or I/O errors. In |
162 | with active (but unsatisifable) read watchers (C<EPIPE>) or I/O errors. In |
164 | cases where the other side can close the connection at their will it is |
163 | cases where the other side can close the connection at will, it is |
165 | often easiest to not report C<EPIPE> errors in this callback. |
164 | often easiest to not report C<EPIPE> errors in this callback. |
166 | |
165 | |
167 | AnyEvent::Handle tries to find an appropriate error code for you to check |
166 | AnyEvent::Handle tries to find an appropriate error code for you to check |
168 | against, but in some cases (TLS errors), this does not work well. It is |
167 | against, but in some cases (TLS errors), this does not work well. It is |
169 | recommended to always output the C<$message> argument in human-readable |
168 | recommended to always output the C<$message> argument in human-readable |
170 | error messages (it's usually the same as C<"$!">). |
169 | error messages (it's usually the same as C<"$!">). |
171 | |
170 | |
172 | Non-fatal errors can be retried by simply returning, but it is recommended |
171 | Non-fatal errors can be retried by returning, but it is recommended |
173 | to simply ignore this parameter and instead abondon the handle object |
172 | to simply ignore this parameter and instead abondon the handle object |
174 | when this callback is invoked. Examples of non-fatal errors are timeouts |
173 | when this callback is invoked. Examples of non-fatal errors are timeouts |
175 | C<ETIMEDOUT>) or badly-formatted data (C<EBADMSG>). |
174 | C<ETIMEDOUT>) or badly-formatted data (C<EBADMSG>). |
176 | |
175 | |
177 | On callback entrance, the value of C<$!> contains the operating system |
176 | On entry to the callback, the value of C<$!> contains the operating |
178 | error code (or C<ENOSPC>, C<EPIPE>, C<ETIMEDOUT>, C<EBADMSG> or |
177 | system error code (or C<ENOSPC>, C<EPIPE>, C<ETIMEDOUT>, C<EBADMSG> or |
179 | C<EPROTO>). |
178 | C<EPROTO>). |
180 | |
179 | |
181 | While not mandatory, it is I<highly> recommended to set this callback, as |
180 | While not mandatory, it is I<highly> recommended to set this callback, as |
182 | you will not be notified of errors otherwise. The default simply calls |
181 | you will not be notified of errors otherwise. The default just calls |
183 | C<croak>. |
182 | C<croak>. |
184 | |
183 | |
185 | =item on_read => $cb->($handle) |
184 | =item on_read => $cb->($handle) |
186 | |
185 | |
187 | This sets the default read callback, which is called when data arrives |
186 | This sets the default read callback, which is called when data arrives |
… | |
… | |
195 | the beginning from it. |
194 | the beginning from it. |
196 | |
195 | |
197 | You can also call C<< ->push_read (...) >> or any other function that |
196 | You can also call C<< ->push_read (...) >> or any other function that |
198 | modifies the read queue. Or do both. Or ... |
197 | modifies the read queue. Or do both. Or ... |
199 | |
198 | |
200 | When an EOF condition is detected then AnyEvent::Handle will first try to |
199 | When an EOF condition is detected, AnyEvent::Handle will first try to |
201 | feed all the remaining data to the queued callbacks and C<on_read> before |
200 | feed all the remaining data to the queued callbacks and C<on_read> before |
202 | calling the C<on_eof> callback. If no progress can be made, then a fatal |
201 | calling the C<on_eof> callback. If no progress can be made, then a fatal |
203 | error will be raised (with C<$!> set to C<EPIPE>). |
202 | error will be raised (with C<$!> set to C<EPIPE>). |
204 | |
203 | |
205 | Note that, unlike requests in the read queue, an C<on_read> callback |
204 | Note that, unlike requests in the read queue, an C<on_read> callback |
… | |
… | |
224 | set, then a fatal error will be raised with C<$!> set to <0>. |
223 | set, then a fatal error will be raised with C<$!> set to <0>. |
225 | |
224 | |
226 | =item on_drain => $cb->($handle) |
225 | =item on_drain => $cb->($handle) |
227 | |
226 | |
228 | This sets the callback that is called when the write buffer becomes empty |
227 | This sets the callback that is called when the write buffer becomes empty |
229 | (or when the callback is set and the buffer is empty already). |
228 | (or immediately if the buffer is empty already). |
230 | |
229 | |
231 | To append to the write buffer, use the C<< ->push_write >> method. |
230 | To append to the write buffer, use the C<< ->push_write >> method. |
232 | |
231 | |
233 | This callback is useful when you don't want to put all of your write data |
232 | This callback is useful when you don't want to put all of your write data |
234 | into the queue at once, for example, when you want to write the contents |
233 | into the queue at once, for example, when you want to write the contents |
… | |
… | |
246 | many seconds pass without a successful read or write on the underlying |
245 | many seconds pass without a successful read or write on the underlying |
247 | file handle (or a call to C<timeout_reset>), the C<on_timeout> callback |
246 | file handle (or a call to C<timeout_reset>), the C<on_timeout> callback |
248 | will be invoked (and if that one is missing, a non-fatal C<ETIMEDOUT> |
247 | will be invoked (and if that one is missing, a non-fatal C<ETIMEDOUT> |
249 | error will be raised). |
248 | error will be raised). |
250 | |
249 | |
251 | There are three variants of the timeouts that work fully independent |
250 | There are three variants of the timeouts that work independently |
252 | of each other, for both read and write, just read, and just write: |
251 | of each other, for both read and write, just read, and just write: |
253 | C<timeout>, C<rtimeout> and C<wtimeout>, with corresponding callbacks |
252 | C<timeout>, C<rtimeout> and C<wtimeout>, with corresponding callbacks |
254 | C<on_timeout>, C<on_rtimeout> and C<on_wtimeout>, and reset functions |
253 | C<on_timeout>, C<on_rtimeout> and C<on_wtimeout>, and reset functions |
255 | C<timeout_reset>, C<rtimeout_reset>, and C<wtimeout_reset>. |
254 | C<timeout_reset>, C<rtimeout_reset>, and C<wtimeout_reset>. |
256 | |
255 | |
257 | Note that timeout processing is also active when you currently do not have |
256 | Note that timeout processing is active even when you do not have |
258 | any outstanding read or write requests: If you plan to keep the connection |
257 | any outstanding read or write requests: If you plan to keep the connection |
259 | idle then you should disable the timout temporarily or ignore the timeout |
258 | idle then you should disable the timeout temporarily or ignore the timeout |
260 | in the C<on_timeout> callback, in which case AnyEvent::Handle will simply |
259 | in the C<on_timeout> callback, in which case AnyEvent::Handle will simply |
261 | restart the timeout. |
260 | restart the timeout. |
262 | |
261 | |
263 | Zero (the default) disables this timeout. |
262 | Zero (the default) disables this timeout. |
264 | |
263 | |
… | |
… | |
280 | amount of data without a callback ever being called as long as the line |
279 | amount of data without a callback ever being called as long as the line |
281 | isn't finished). |
280 | isn't finished). |
282 | |
281 | |
283 | =item autocork => <boolean> |
282 | =item autocork => <boolean> |
284 | |
283 | |
285 | When disabled (the default), then C<push_write> will try to immediately |
284 | When disabled (the default), C<push_write> will try to immediately |
286 | write the data to the handle, if possible. This avoids having to register |
285 | write the data to the handle if possible. This avoids having to register |
287 | a write watcher and wait for the next event loop iteration, but can |
286 | a write watcher and wait for the next event loop iteration, but can |
288 | be inefficient if you write multiple small chunks (on the wire, this |
287 | be inefficient if you write multiple small chunks (on the wire, this |
289 | disadvantage is usually avoided by your kernel's nagle algorithm, see |
288 | disadvantage is usually avoided by your kernel's nagle algorithm, see |
290 | C<no_delay>, but this option can save costly syscalls). |
289 | C<no_delay>, but this option can save costly syscalls). |
291 | |
290 | |
292 | When enabled, then writes will always be queued till the next event loop |
291 | When enabled, writes will always be queued till the next event loop |
293 | iteration. This is efficient when you do many small writes per iteration, |
292 | iteration. This is efficient when you do many small writes per iteration, |
294 | but less efficient when you do a single write only per iteration (or when |
293 | but less efficient when you do a single write only per iteration (or when |
295 | the write buffer often is full). It also increases write latency. |
294 | the write buffer often is full). It also increases write latency. |
296 | |
295 | |
297 | =item no_delay => <boolean> |
296 | =item no_delay => <boolean> |
… | |
… | |
301 | the Nagle algorithm, and usually it is beneficial. |
300 | the Nagle algorithm, and usually it is beneficial. |
302 | |
301 | |
303 | In some situations you want as low a delay as possible, which can be |
302 | In some situations you want as low a delay as possible, which can be |
304 | accomplishd by setting this option to a true value. |
303 | accomplishd by setting this option to a true value. |
305 | |
304 | |
306 | The default is your opertaing system's default behaviour (most likely |
305 | The default is your operating system's default behaviour (most likely |
307 | enabled), this option explicitly enables or disables it, if possible. |
306 | enabled). This option explicitly enables or disables it, if possible. |
308 | |
307 | |
309 | =item keepalive => <boolean> |
308 | =item keepalive => <boolean> |
310 | |
309 | |
311 | Enables (default disable) the SO_KEEPALIVE option on the stream socket: |
310 | Enables (default disable) the SO_KEEPALIVE option on the stream socket: |
312 | normally, TCP connections have no time-out once established, so TCP |
311 | normally, TCP connections have no time-out once established, so TCP |
313 | connections, once established, can stay alive forever even when the other |
312 | connections, once established, can stay alive forever even when the other |
314 | side has long gone. TCP keepalives are a cheap way to take down long-lived |
313 | side has long gone. TCP keepalives are a cheap way to take down long-lived |
315 | TCP connections whent he other side becomes unreachable. While the default |
314 | TCP connections when the other side becomes unreachable. While the default |
316 | is OS-dependent, TCP keepalives usually kick in after around two hours, |
315 | is OS-dependent, TCP keepalives usually kick in after around two hours, |
317 | and, if the other side doesn't reply, take down the TCP connection some 10 |
316 | and, if the other side doesn't reply, take down the TCP connection some 10 |
318 | to 15 minutes later. |
317 | to 15 minutes later. |
319 | |
318 | |
320 | It is harmless to specify this option for file handles that do not support |
319 | It is harmless to specify this option for file handles that do not support |
… | |
… | |
338 | already have occured on BSD systems), but at least it will protect you |
337 | already have occured on BSD systems), but at least it will protect you |
339 | from most attacks. |
338 | from most attacks. |
340 | |
339 | |
341 | =item read_size => <bytes> |
340 | =item read_size => <bytes> |
342 | |
341 | |
343 | The default read block size (the amount of bytes this module will |
342 | The default read block size (the number of bytes this module will |
344 | try to read during each loop iteration, which affects memory |
343 | try to read during each loop iteration, which affects memory |
345 | requirements). Default: C<8192>. |
344 | requirements). Default: C<8192>. |
346 | |
345 | |
347 | =item low_water_mark => <bytes> |
346 | =item low_water_mark => <bytes> |
348 | |
347 | |
349 | Sets the amount of bytes (default: C<0>) that make up an "empty" write |
348 | Sets the number of bytes (default: C<0>) that make up an "empty" write |
350 | buffer: If the write reaches this size or gets even samller it is |
349 | buffer: If the buffer reaches this size or gets even samller it is |
351 | considered empty. |
350 | considered empty. |
352 | |
351 | |
353 | Sometimes it can be beneficial (for performance reasons) to add data to |
352 | Sometimes it can be beneficial (for performance reasons) to add data to |
354 | the write buffer before it is fully drained, but this is a rare case, as |
353 | the write buffer before it is fully drained, but this is a rare case, as |
355 | the operating system kernel usually buffers data as well, so the default |
354 | the operating system kernel usually buffers data as well, so the default |
356 | is good in almost all cases. |
355 | is good in almost all cases. |
357 | |
356 | |
358 | =item linger => <seconds> |
357 | =item linger => <seconds> |
359 | |
358 | |
360 | If non-zero (default: C<3600>), then the destructor of the |
359 | If this is non-zero (default: C<3600>), the destructor of the |
361 | AnyEvent::Handle object will check whether there is still outstanding |
360 | AnyEvent::Handle object will check whether there is still outstanding |
362 | write data and will install a watcher that will write this data to the |
361 | write data and will install a watcher that will write this data to the |
363 | socket. No errors will be reported (this mostly matches how the operating |
362 | socket. No errors will be reported (this mostly matches how the operating |
364 | system treats outstanding data at socket close time). |
363 | system treats outstanding data at socket close time). |
365 | |
364 | |
… | |
… | |
372 | A string used to identify the remote site - usually the DNS hostname |
371 | A string used to identify the remote site - usually the DNS hostname |
373 | (I<not> IDN!) used to create the connection, rarely the IP address. |
372 | (I<not> IDN!) used to create the connection, rarely the IP address. |
374 | |
373 | |
375 | Apart from being useful in error messages, this string is also used in TLS |
374 | Apart from being useful in error messages, this string is also used in TLS |
376 | peername verification (see C<verify_peername> in L<AnyEvent::TLS>). This |
375 | peername verification (see C<verify_peername> in L<AnyEvent::TLS>). This |
377 | verification will be skipped when C<peername> is not specified or |
376 | verification will be skipped when C<peername> is not specified or is |
378 | C<undef>. |
377 | C<undef>. |
379 | |
378 | |
380 | =item tls => "accept" | "connect" | Net::SSLeay::SSL object |
379 | =item tls => "accept" | "connect" | Net::SSLeay::SSL object |
381 | |
380 | |
382 | When this parameter is given, it enables TLS (SSL) mode, that means |
381 | When this parameter is given, it enables TLS (SSL) mode, that means |
… | |
… | |
408 | B<IMPORTANT:> since Net::SSLeay "objects" are really only integers, |
407 | B<IMPORTANT:> since Net::SSLeay "objects" are really only integers, |
409 | passing in the wrong integer will lead to certain crash. This most often |
408 | passing in the wrong integer will lead to certain crash. This most often |
410 | happens when one uses a stylish C<< tls => 1 >> and is surprised about the |
409 | happens when one uses a stylish C<< tls => 1 >> and is surprised about the |
411 | segmentation fault. |
410 | segmentation fault. |
412 | |
411 | |
413 | See the C<< ->starttls >> method for when need to start TLS negotiation later. |
412 | Use the C<< ->starttls >> method if you need to start TLS negotiation later. |
414 | |
413 | |
415 | =item tls_ctx => $anyevent_tls |
414 | =item tls_ctx => $anyevent_tls |
416 | |
415 | |
417 | Use the given C<AnyEvent::TLS> object to create the new TLS connection |
416 | Use the given C<AnyEvent::TLS> object to create the new TLS connection |
418 | (unless a connection object was specified directly). If this parameter is |
417 | (unless a connection object was specified directly). If this parameter is |
… | |
… | |
433 | |
432 | |
434 | TLS handshake failures will not cause C<on_error> to be invoked when this |
433 | TLS handshake failures will not cause C<on_error> to be invoked when this |
435 | callback is in effect, instead, the error message will be passed to C<on_starttls>. |
434 | callback is in effect, instead, the error message will be passed to C<on_starttls>. |
436 | |
435 | |
437 | Without this callback, handshake failures lead to C<on_error> being |
436 | Without this callback, handshake failures lead to C<on_error> being |
438 | called, as normal. |
437 | called as usual. |
439 | |
438 | |
440 | Note that you cannot call C<starttls> right again in this callback. If you |
439 | Note that you cannot just call C<starttls> again in this callback. If you |
441 | need to do that, start an zero-second timer instead whose callback can |
440 | need to do that, start an zero-second timer instead whose callback can |
442 | then call C<< ->starttls >> again. |
441 | then call C<< ->starttls >> again. |
443 | |
442 | |
444 | =item on_stoptls => $cb->($handle) |
443 | =item on_stoptls => $cb->($handle) |
445 | |
444 | |
… | |
… | |
1117 | partial message has been received so far), or change the read queue with |
1116 | partial message has been received so far), or change the read queue with |
1118 | e.g. C<push_read>. |
1117 | e.g. C<push_read>. |
1119 | |
1118 | |
1120 | In the more complex case, you want to queue multiple callbacks. In this |
1119 | In the more complex case, you want to queue multiple callbacks. In this |
1121 | case, AnyEvent::Handle will call the first queued callback each time new |
1120 | case, AnyEvent::Handle will call the first queued callback each time new |
1122 | data arrives (also the first time it is queued) and removes it when it has |
1121 | data arrives (also the first time it is queued) and remove it when it has |
1123 | done its job (see C<push_read>, below). |
1122 | done its job (see C<push_read>, below). |
1124 | |
1123 | |
1125 | This way you can, for example, push three line-reads, followed by reading |
1124 | This way you can, for example, push three line-reads, followed by reading |
1126 | a chunk of data, and AnyEvent::Handle will execute them in order. |
1125 | a chunk of data, and AnyEvent::Handle will execute them in order. |
1127 | |
1126 | |
… | |
… | |
1461 | the receive buffer when neither C<$accept> nor C<$reject> match, |
1460 | the receive buffer when neither C<$accept> nor C<$reject> match, |
1462 | and everything preceding and including the match will be accepted |
1461 | and everything preceding and including the match will be accepted |
1463 | unconditionally. This is useful to skip large amounts of data that you |
1462 | unconditionally. This is useful to skip large amounts of data that you |
1464 | know cannot be matched, so that the C<$accept> or C<$reject> regex do not |
1463 | know cannot be matched, so that the C<$accept> or C<$reject> regex do not |
1465 | have to start matching from the beginning. This is purely an optimisation |
1464 | have to start matching from the beginning. This is purely an optimisation |
1466 | and is usually worth only when you expect more than a few kilobytes. |
1465 | and is usually worth it only when you expect more than a few kilobytes. |
1467 | |
1466 | |
1468 | Example: expect a http header, which ends at C<\015\012\015\012>. Since we |
1467 | Example: expect a http header, which ends at C<\015\012\015\012>. Since we |
1469 | expect the header to be very large (it isn't in practise, but...), we use |
1468 | expect the header to be very large (it isn't in practice, but...), we use |
1470 | a skip regex to skip initial portions. The skip regex is tricky in that |
1469 | a skip regex to skip initial portions. The skip regex is tricky in that |
1471 | it only accepts something not ending in either \015 or \012, as these are |
1470 | it only accepts something not ending in either \015 or \012, as these are |
1472 | required for the accept regex. |
1471 | required for the accept regex. |
1473 | |
1472 | |
1474 | $handle->push_read (regex => |
1473 | $handle->push_read (regex => |
… | |
… | |
1874 | context in C<< $handle->{tls_ctx} >> after this call and can be used or |
1873 | context in C<< $handle->{tls_ctx} >> after this call and can be used or |
1875 | changed to your liking. Note that the handshake might have already started |
1874 | changed to your liking. Note that the handshake might have already started |
1876 | when this function returns. |
1875 | when this function returns. |
1877 | |
1876 | |
1878 | Due to bugs in OpenSSL, it might or might not be possible to do multiple |
1877 | Due to bugs in OpenSSL, it might or might not be possible to do multiple |
1879 | handshakes on the same stream. Best do not attempt to use the stream after |
1878 | handshakes on the same stream. It is best to not attempt to use the |
1880 | stopping TLS. |
1879 | stream after stopping TLS. |
1881 | |
1880 | |
1882 | This method may invoke callbacks (and therefore the handle might be |
1881 | This method may invoke callbacks (and therefore the handle might be |
1883 | destroyed after it returns). |
1882 | destroyed after it returns). |
1884 | |
1883 | |
1885 | =cut |
1884 | =cut |
… | |
… | |
2115 | |
2114 | |
2116 | =item I get different callback invocations in TLS mode/Why can't I pause |
2115 | =item I get different callback invocations in TLS mode/Why can't I pause |
2117 | reading? |
2116 | reading? |
2118 | |
2117 | |
2119 | Unlike, say, TCP, TLS connections do not consist of two independent |
2118 | Unlike, say, TCP, TLS connections do not consist of two independent |
2120 | communication channels, one for each direction. Or put differently. The |
2119 | communication channels, one for each direction. Or put differently, the |
2121 | read and write directions are not independent of each other: you cannot |
2120 | read and write directions are not independent of each other: you cannot |
2122 | write data unless you are also prepared to read, and vice versa. |
2121 | write data unless you are also prepared to read, and vice versa. |
2123 | |
2122 | |
2124 | This can mean than, in TLS mode, you might get C<on_error> or C<on_eof> |
2123 | This means that, in TLS mode, you might get C<on_error> or C<on_eof> |
2125 | callback invocations when you are not expecting any read data - the reason |
2124 | callback invocations when you are not expecting any read data - the reason |
2126 | is that AnyEvent::Handle always reads in TLS mode. |
2125 | is that AnyEvent::Handle always reads in TLS mode. |
2127 | |
2126 | |
2128 | During the connection, you have to make sure that you always have a |
2127 | During the connection, you have to make sure that you always have a |
2129 | non-empty read-queue, or an C<on_read> watcher. At the end of the |
2128 | non-empty read-queue, or an C<on_read> watcher. At the end of the |
… | |
… | |
2143 | my $data = delete $_[0]{rbuf}; |
2142 | my $data = delete $_[0]{rbuf}; |
2144 | }); |
2143 | }); |
2145 | |
2144 | |
2146 | The reason to use C<on_error> is that TCP connections, due to latencies |
2145 | The reason to use C<on_error> is that TCP connections, due to latencies |
2147 | and packets loss, might get closed quite violently with an error, when in |
2146 | and packets loss, might get closed quite violently with an error, when in |
2148 | fact, all data has been received. |
2147 | fact all data has been received. |
2149 | |
2148 | |
2150 | It is usually better to use acknowledgements when transferring data, |
2149 | It is usually better to use acknowledgements when transferring data, |
2151 | to make sure the other side hasn't just died and you got the data |
2150 | to make sure the other side hasn't just died and you got the data |
2152 | intact. This is also one reason why so many internet protocols have an |
2151 | intact. This is also one reason why so many internet protocols have an |
2153 | explicit QUIT command. |
2152 | explicit QUIT command. |
… | |
… | |
2170 | consider using C<< ->push_shutdown >> instead. |
2169 | consider using C<< ->push_shutdown >> instead. |
2171 | |
2170 | |
2172 | =item I want to contact a TLS/SSL server, I don't care about security. |
2171 | =item I want to contact a TLS/SSL server, I don't care about security. |
2173 | |
2172 | |
2174 | If your TLS server is a pure TLS server (e.g. HTTPS) that only speaks TLS, |
2173 | If your TLS server is a pure TLS server (e.g. HTTPS) that only speaks TLS, |
2175 | simply connect to it and then create the AnyEvent::Handle with the C<tls> |
2174 | connect to it and then create the AnyEvent::Handle with the C<tls> |
2176 | parameter: |
2175 | parameter: |
2177 | |
2176 | |
2178 | tcp_connect $host, $port, sub { |
2177 | tcp_connect $host, $port, sub { |
2179 | my ($fh) = @_; |
2178 | my ($fh) = @_; |
2180 | |
2179 | |
… | |
… | |
2280 | |
2279 | |
2281 | =item * all members not documented here and not prefixed with an underscore |
2280 | =item * all members not documented here and not prefixed with an underscore |
2282 | are free to use in subclasses. |
2281 | are free to use in subclasses. |
2283 | |
2282 | |
2284 | Of course, new versions of AnyEvent::Handle may introduce more "public" |
2283 | Of course, new versions of AnyEvent::Handle may introduce more "public" |
2285 | member variables, but thats just life, at least it is documented. |
2284 | member variables, but that's just life. At least it is documented. |
2286 | |
2285 | |
2287 | =back |
2286 | =back |
2288 | |
2287 | |
2289 | =head1 AUTHOR |
2288 | =head1 AUTHOR |
2290 | |
2289 | |