| … | |
… | |
| 1128 | |
1128 | |
| 1129 | Whenever the given C<type> is used, C<push_write> will the function with |
1129 | Whenever the given C<type> is used, C<push_write> will the function with |
| 1130 | the handle object and the remaining arguments. |
1130 | the handle object and the remaining arguments. |
| 1131 | |
1131 | |
| 1132 | The function is supposed to return a single octet string that will be |
1132 | The function is supposed to return a single octet string that will be |
| 1133 | appended to the write buffer, so you cna mentally treat this function as a |
1133 | appended to the write buffer, so you can mentally treat this function as a |
| 1134 | "arguments to on-the-wire-format" converter. |
1134 | "arguments to on-the-wire-format" converter. |
| 1135 | |
1135 | |
| 1136 | Example: implement a custom write type C<join> that joins the remaining |
1136 | Example: implement a custom write type C<join> that joins the remaining |
| 1137 | arguments using the first one. |
1137 | arguments using the first one. |
| 1138 | |
1138 | |
| … | |
… | |
| 2204 | Probably because your C<on_error> callback is being called instead: When |
2204 | Probably because your C<on_error> callback is being called instead: When |
| 2205 | you have outstanding requests in your read queue, then an EOF is |
2205 | you have outstanding requests in your read queue, then an EOF is |
| 2206 | considered an error as you clearly expected some data. |
2206 | considered an error as you clearly expected some data. |
| 2207 | |
2207 | |
| 2208 | To avoid this, make sure you have an empty read queue whenever your handle |
2208 | To avoid this, make sure you have an empty read queue whenever your handle |
| 2209 | is supposed to be "idle" (i.e. connection closes are O.K.). You cna set |
2209 | is supposed to be "idle" (i.e. connection closes are O.K.). You can set |
| 2210 | an C<on_read> handler that simply pushes the first read requests in the |
2210 | an C<on_read> handler that simply pushes the first read requests in the |
| 2211 | queue. |
2211 | queue. |
| 2212 | |
2212 | |
| 2213 | See also the next question, which explains this in a bit more detail. |
2213 | See also the next question, which explains this in a bit more detail. |
| 2214 | |
2214 | |
| … | |
… | |
| 2245 | some data and raises the C<EPIPE> error when the connction is dropped |
2245 | some data and raises the C<EPIPE> error when the connction is dropped |
| 2246 | unexpectedly. |
2246 | unexpectedly. |
| 2247 | |
2247 | |
| 2248 | The second variant is a protocol where the client can drop the connection |
2248 | The second variant is a protocol where the client can drop the connection |
| 2249 | at any time. For TCP, this means that the server machine may run out of |
2249 | at any time. For TCP, this means that the server machine may run out of |
| 2250 | sockets easier, and in general, it means you cnanot distinguish a protocl |
2250 | sockets easier, and in general, it means you cannot distinguish a protocl |
| 2251 | failure/client crash from a normal connection close. Nevertheless, these |
2251 | failure/client crash from a normal connection close. Nevertheless, these |
| 2252 | kinds of protocols are common (and sometimes even the best solution to the |
2252 | kinds of protocols are common (and sometimes even the best solution to the |
| 2253 | problem). |
2253 | problem). |
| 2254 | |
2254 | |
| 2255 | Having an outstanding read request at all times is possible if you ignore |
2255 | Having an outstanding read request at all times is possible if you ignore |
