| … | |
… | |
| 2135 | |
2135 | |
| 2136 | It is only safe to "forget" the reference inside EOF or error callbacks, |
2136 | It is only safe to "forget" the reference inside EOF or error callbacks, |
| 2137 | from within all other callbacks, you need to explicitly call the C<< |
2137 | from within all other callbacks, you need to explicitly call the C<< |
| 2138 | ->destroy >> method. |
2138 | ->destroy >> method. |
| 2139 | |
2139 | |
|
|
2140 | =item Why is my C<on_eof> callback never called? |
|
|
2141 | |
|
|
2142 | Probably because your C<on_error> callback is being called instead: When |
|
|
2143 | you have outstanding requests in your read queue, then an EOF is |
|
|
2144 | considered an error as you clearly expected some data. |
|
|
2145 | |
|
|
2146 | To avoid this, make sure you have an empty read queue whenever your handle |
|
|
2147 | is supposed to be "idle" (i.e. connection closes are O.K.). You cna set |
|
|
2148 | an C<on_read> handler that simply pushes the first read requests in the |
|
|
2149 | queue. |
|
|
2150 | |
|
|
2151 | See also the next question, which explains this in a bit more detail. |
|
|
2152 | |
|
|
2153 | =item How can I serve requests in a loop? |
|
|
2154 | |
|
|
2155 | Most protocols consist of some setup phase (authentication for example) |
|
|
2156 | followed by a request handling phase, where the server waits for requests |
|
|
2157 | and handles them, in a loop. |
|
|
2158 | |
|
|
2159 | There are two important variants: The first (traditional, better) variant |
|
|
2160 | handles requests until the server gets some QUIT command, causing it to |
|
|
2161 | close the connection first (highly desirable for a busy TCP server). A |
|
|
2162 | client dropping the connection is an error, which means this variant can |
|
|
2163 | detect an unexpected detection close. |
|
|
2164 | |
|
|
2165 | To handle this case, always make sure you have a on-empty read queue, by |
|
|
2166 | pushing the "read request start" handler on it: |
|
|
2167 | |
|
|
2168 | # we assume a request starts with a single line |
|
|
2169 | my @start_request; @start_request = (line => sub { |
|
|
2170 | my ($hdl, $line) = @_; |
|
|
2171 | |
|
|
2172 | ... handle request |
|
|
2173 | |
|
|
2174 | # push next request read, possibly from a nested callback |
|
|
2175 | $hdl->push_read (@start_request); |
|
|
2176 | }); |
|
|
2177 | |
|
|
2178 | # auth done, now go into request handling loop |
|
|
2179 | # now push the first @start_request |
|
|
2180 | $hdl->push_read (@start_request); |
|
|
2181 | |
|
|
2182 | By always having an outstanding C<push_read>, the handle always expects |
|
|
2183 | some data and raises the C<EPIPE> error when the connction is dropped |
|
|
2184 | unexpectedly. |
|
|
2185 | |
|
|
2186 | The second variant is a protocol where the client can drop the connection |
|
|
2187 | at any time. For TCP, this means that the server machine may run out of |
|
|
2188 | sockets easier, and in general, it means you cnanot distinguish a protocl |
|
|
2189 | failure/client crash from a normal connection close. Nevertheless, these |
|
|
2190 | kinds of protocols are common (and sometimes even the best solution to the |
|
|
2191 | problem). |
|
|
2192 | |
|
|
2193 | Having an outstanding read request at all times is possible if you ignore |
|
|
2194 | C<EPIPE> errors, but this doesn't help with when the client drops the |
|
|
2195 | connection during a request, which would still be an error. |
|
|
2196 | |
|
|
2197 | A better solution is to push the initial request read in an C<on_read> |
|
|
2198 | callback. This avoids an error, as when the server doesn't expect data |
|
|
2199 | (i.e. is idly waiting for the next request, an EOF will not raise an |
|
|
2200 | error, but simply result in an C<on_eof> callback. It is also a bit slower |
|
|
2201 | and simpler: |
|
|
2202 | |
|
|
2203 | # auth done, now go into request handling loop |
|
|
2204 | $hdl->on_read (sub { |
|
|
2205 | my ($hdl) = @_; |
|
|
2206 | |
|
|
2207 | # called each time we receive data but the read queue is empty |
|
|
2208 | # simply start read the request |
|
|
2209 | |
|
|
2210 | $hdl->push_read (line => sub { |
|
|
2211 | my ($hdl, $line) = @_; |
|
|
2212 | |
|
|
2213 | ... handle request |
|
|
2214 | |
|
|
2215 | # do nothing special when the request has been handled, just |
|
|
2216 | # let the request queue go empty. |
|
|
2217 | }); |
|
|
2218 | }); |
|
|
2219 | |
| 2140 | =item I get different callback invocations in TLS mode/Why can't I pause |
2220 | =item I get different callback invocations in TLS mode/Why can't I pause |
| 2141 | reading? |
2221 | reading? |
| 2142 | |
2222 | |
| 2143 | Unlike, say, TCP, TLS connections do not consist of two independent |
2223 | Unlike, say, TCP, TLS connections do not consist of two independent |
| 2144 | communication channels, one for each direction. Or put differently, the |
2224 | communication channels, one for each direction. Or put differently, the |
