On Fri, 8 May 2020 at 19:14, Gordon Sim <[email protected]> wrote: > > On 08/05/2020 3:57 pm, Michael Ivanov wrote: > > I am using pn_messenger_t interface in my private select-based event loop. > > I use pn_selectable_t to trigger actual i/o. > > > > As far as I have seen in proton/c source pn_transport_tick is invoked only > > from pni_messenger_tick, which is in turn called from pn_messenger_process > > only. I do not call the latter explicitly and I do not invoke anything > > to set any idle timeout interval inside pn_messenger. > > > > pn_transport_tick() just invokes function, pointed to by process_tick of > > pn_io_layer_t structure: but I could not find where this field is set. > > Ok, I'm not sure if heartbeats have been thought through for the > messenger interface, particularly where you are driving the io yourself.
Probably not, heartbeat support was only added later originally I think, plus Messenger was originally 'drives own IO' from my limited recall. Other routes may have come later but probably not fully considered as you say. More so given that lead to other bits being created, with Messenger being deprecated years ago and removed from the various bindings. > > > Can I use pn_message_t to send heartbeat explicitly? > No, heartbeats are entirely empty AMQP frames, not higher level empty messages or empty message-transfer frames, so theres not an exposed way to send them. > Heartbeats are only needed in the absence of other traffic, so if you > send messages frequently enough there is no need for heartbeats. > > I suspect there is no way of reading the idle-timeout advertised by the > broker through the messenger interface, but from the protocol trace it > is 1 minute. So if you send messages more frequently than that it will > not disconnect you (in practice it is likely to wait double that timeout > before giving up). > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
