[cups-devel] IPP requests: Non-blocking or short timeout

[Michael Sweet]

Till,

> On Sep 12, 2016, at 9:33 AM, Till Kamppeter <till.kamppeter at gmail.com> wrote:
> 
> Thank you very much for the help.
> 
> On 09/11/2016 03:22 PM, Michael Sweet wrote:
>> The httpSetTimeout function can be used to manipulate the default read timeout for a given connection. But cupsDoRequest also attempts to reconnect on error (using a connection timeout of 30 seconds) so you might want to use cupsSendRequest and cupsGetResponse yourself to control the reconnect behavior...
>> 
> 
> I have tried the cupsSendRequest()/cupsGetResponse() now and what happens is that cupsSendRequest() exits immediately with some OK status and cupsGetResponse() hangs for more than one minute with status 100 (HTTP_STATUS_CONTINUE). So the problem is that the server does not answer in time.

Hmm, can you get a packet trace showing the traffic?

> Calling "httpSetTimeout(http, 3, NULL, NULL);" before (3 sec timeout) does not help. Or do I have to define a callback here (which would for example kill the connection after the three seconds which I chosen as timeout). If I need a callback, how should it look like?

The test/ipptool.c program has a fairly sophisticated one, but if you don't specify a callback it should timeout after the 3 seconds you specify.

If you can compile and install CUPS with "--enable-debug-printfs", run cups-browsed (or a test program) against that libcups.so.2 with:

    CUPS_DEBUG_LOG=debug.log CUPS_DEBUG_LEVEL=6 CUPS_DEBUG_FILTER="^(http|ipp|cupsDo|cupsGet|cupsSend)" LD_LIBRARY_PATH=/path/to/cups/source/dir/cups cups-browsed-command

then send me the "debug.log" file along with the packet trace.  Something isn't right if the timeouts are not working - we depend on it for ipptool's timeout support, for example.

_________________________________________________________
Michael Sweet, Senior Printing System Engineer