PROTON-2275: Fixed idle_timeout connection option not working for SSL connections on Windows.

[attila-kun]

Steps to reproduce:

1. Connect your receiver to an SSL-capable broker. The receiver has to be running on Windows.
2. Set the idle_timeout connection option to e.g. 2 seconds in your proton::messaging_handler instance.
3. In the on_message callback, sleep for longer than idle_timeout. This should trigger the on_transport_error callback with a amqp:resource-limit-exceeded: local-idle-timeout expired error. On Windows this does not happen.

I saw that the above scenario worked correctly when connecting to a non-SSL broker but failed with an SSL broker. I looked at the difference between the two code paths and found that for the same input (transport->output_buffer being empty and transport->close_sent == true) transport.c returns PN_EOS while schannel.c returned 0. After ensuring that schannel.c matches the behaviour of transport.c, the problem went away.

[attila-kun]

@astitcher @jiridanek : Is there anything I can do to make sure this gets merged soon?

[gemmellr]

A start would be to create a JIRA to allow tracking the issue, rebasing your commit against master (rather than merging master), and reference the JIRA in your commit (see existing commits).

[attila-kun]

@gemmellr It's done.

[gemmellr]

Thanks. Hopefully one of the C-inclined folks will be along to review the change.

[cpt-codes]

Hi @gemmellr. I've come across the same issue using version 0.37.0 through vcpkg (happened to be the version I had installed, and I couldn't see any changes related to this in newer versions). I applied this little fix and it seems to work a treat. Any chance this could be reviewed soon?

[gemmellr]

@cliffjansen @astitcher ^

[astitcher]

I'm not sure that this fix is in the correct layer, as the openssl code works correctly (it does right?)

[astitcher]

I'm somewhat confused about this change - the equivalent openssl code does not do anything like this but as far as I know works correctly in the face of idle timeout. This makes me think that this is not the correct fix to the problem.
Especially as the check should be redundent in that the amqp layer processing which does have this check will still be running and should pick up on the issue. Clearly there is an issue somewhere that is specific to the schannel implementation, but this seems like a 'voodoo' fix.
@cliffjansen @kgiusti do either of you have any thoughts?