Empty frame

[Tomáš Šoltys <to...@gmail.com>]

Hi,

I am looking for a way hot to send a heartbeat. I have found something
about sending an empty frame and pn_transport_set_idle_timeout()

Is this somewhat related? Is there a way how to send/receive heartbeats?

Thanks and regards,
Tomas

Re: Empty frame

[Gordon Sim <gs...@redhat.com>]

On 07/29/2015 02:39 PM, Tomáš Šoltys wrote:
> Does this mean that for example I will set timeout to 10 seconds and
> message processing in PN_TRANSFER will take 1 minute or more that
> connection will eventually timeout?
> Is my assumption correct?

What you set as the idle timeout determines the rate at which the remote 
peer must send heartbeats (or other traffic). What the remote peer 
specifies as their idle timeout determines the rate the local process 
must send out heartbeats.

If you don't process the connection (call pn_transport_tick and write 
out any data from the transport to the wire) sufficiently frequently 
then the heartbeats won't be sent sufficiently frequently and the remote 
peer may time out the connection.

Likewise, detecting the connection is idle locally involves calling 
on_transport_tick sufficiently frequently. I'm not entirely sure how the 
code works internall, so I don't know for example whether it would 
timeout the connection if the heartbeats that had arrived on the local 
socket were pumped into the transport late. I suspect that is down to 
the order of processing input and calling on_transport_tick.

In generaly though, you want to ensure that you can process the 
connection (do any input and output and call tick) in a timely manner, 
and if you need to do any task that may prevent that, it should be done 
on a separate thread (or written in such a way that it doesn't require 
the thread to be blocked from any other wokr for the duration of the task).

Re: Empty frame

[Tomáš Šoltys <to...@gmail.com>]

Hi Gordon,

Thanks a lot for help.

Does this mean that for example I will set timeout to 10 seconds and
message processing in PN_TRANSFER will take 1 minute or more that
connection will eventually timeout?
Is my assumption correct?

Thanks and regards,
Tomas

2015-07-28 13:09 GMT+02:00 Gordon Sim <gs...@redhat.com>:

> On 07/28/2015 10:57 AM, Tomáš Šoltys wrote:
>
>> So to make it work it is enough to set idle timeout on both sides and
>> proton will handle rest?
>>
>
> If an idle timeout is set by the local application, then proton will raise
> an error if there is no incoming traffic for that time.
>
> If an idle timeout is specified by the remote peer, proton will emit empty
> frames into its output stream provided the pn_transport_tick() function is
> called frequently enough.
>
>  Is heartbeat being sent by pn_transport_tick() ?
>> If so in what event it should be sent? In PN_TRANSPORT ?
>>
>
> Yes, the pn_transport_tick will trigger the writing of empty frames to the
> transport and this should result in a transport event as for any other
> write.
>



-- 
Tomáš Šoltys
tomas.soltys@gmail.com
http://www.range-software.com
(+420) 776-843-663

Re: Empty frame

[Gordon Sim <gs...@redhat.com>]

On 07/28/2015 10:57 AM, Tomáš Šoltys wrote:
> So to make it work it is enough to set idle timeout on both sides and
> proton will handle rest?

If an idle timeout is set by the local application, then proton will 
raise an error if there is no incoming traffic for that time.

If an idle timeout is specified by the remote peer, proton will emit 
empty frames into its output stream provided the pn_transport_tick() 
function is called frequently enough.

> Is heartbeat being sent by pn_transport_tick() ?
> If so in what event it should be sent? In PN_TRANSPORT ?

Yes, the pn_transport_tick will trigger the writing of empty frames to 
the transport and this should result in a transport event as for any 
other write.

Re: Empty frame

[Tomáš Šoltys <to...@gmail.com>]

Hi Gordon,

thanks for the answer.

So to make it work it is enough to set idle timeout on both sides and
proton will handle rest?

Is heartbeat being sent by pn_transport_tick() ?
If so in what event it should be sent? In PN_TRANSPORT ?

Regards,
Tomas

2015-07-28 11:01 GMT+02:00 Gordon Sim <gs...@redhat.com>:

> On 07/28/2015 08:17 AM, Tomáš Šoltys wrote:
>
>> Hi,
>>
>> I am looking for a way hot to send a heartbeat. I have found something
>> about sending an empty frame and pn_transport_set_idle_timeout()
>>
>> Is this somewhat related? Is there a way how to send/receive heartbeats?
>>
>
> In AMQP 1.0, heartbeats are configured separately in each direction. That
> is, each of the connected processes indicates how frequently the remote
> peer should send some traffic in order to prevent the connection timing out
> due to being idle.
>
> So in proton, to indicate to the remote peer that they should send
> heartbeats, you do indeed set the idle timeout. Proton will advertise half
> that time to the peer such that they should then send heartbeats frequently
> enough to avoid the connection timing out when connected.
>
> The sending out of heartbeats by the local peer is controlled by the
> remote peer and whatever idle timeout it has advertised.
>
>


-- 
Tomáš Šoltys
tomas.soltys@gmail.com
http://www.range-software.com
(+420) 776-843-663

Re: Empty frame

[Gordon Sim <gs...@redhat.com>]

On 07/28/2015 08:17 AM, Tomáš Šoltys wrote:
> Hi,
>
> I am looking for a way hot to send a heartbeat. I have found something
> about sending an empty frame and pn_transport_set_idle_timeout()
>
> Is this somewhat related? Is there a way how to send/receive heartbeats?

In AMQP 1.0, heartbeats are configured separately in each direction. 
That is, each of the connected processes indicates how frequently the 
remote peer should send some traffic in order to prevent the connection 
timing out due to being idle.

So in proton, to indicate to the remote peer that they should send 
heartbeats, you do indeed set the idle timeout. Proton will advertise 
half that time to the peer such that they should then send heartbeats 
frequently enough to avoid the connection timing out when connected.

The sending out of heartbeats by the local peer is controlled by the 
remote peer and whatever idle timeout it has advertised.