> > + > > + /* Update the heartbeat timer immediately. */ > > + if (!mod_timer(&trans->hb_timer, > > + sctp_transport_timeout(trans))) > > + sctp_transport_hold(trans); > > This is causes a rather inconsistent behavior in that it doesn't > account of the amount of time left on the hb timer. Thus it doesn't > always do what commit log implies. If the remaining time is shorter > then the new timeout value, it will take longer till the next HB > the application expects. Being able to stop heartbeats being sent by repeatedly configuring the interval is certainly not a good idea! > If the application has very strict timing requirement on the HBs, it > should trigger the HB manually. > > We could rework the code to allow the combination of > SPP_HB_DEMAND | SPP_HB_ENABLE to work as follows: > 1) update the timer to the new value > 2) Send an immediate HB > a) Update the hb timeout. > > 2a should probably be done regardless since it can cause 2 HB to be > outstanding at the same time. Sending a heartbeat 'on demand' might be problematic if one has also just been sent (from the timer). I'd have thought that you wouldn't want to send a heartbeat while still expecting a response from the previous one (this might require splitting the time interval in two). David -- To unsubscribe from this list: send the line "unsubscribe linux-sctp" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
