Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.realtime > #405 > unrolled thread

UDP timers

Back to article view | Back to comp.realtime

Contents

  UDP timers Don Y <this@isnotme.com> - 2014-01-03 14:03 -0700

#405 — UDP timers

Hi,

I've been discussing this in another forum and we haven't (yet!)
come up with any generic approaches that can be bent to the task.
So, I figured it was worth exploring, here...

I've got some UDP-based protocols that try to be really lean
(hence the avoidance of TCP!).  They also must provide certain
timeliness guarantees for the mechanisms that rely on them.
And, reliable delivery (heh heh heh).

Deployed, the network configuration is either known a priori
or network discovery *at* deployment suffices (thereafter,
networks are *very* static!).  Networks are intended to be
private and contain only "well behaved" devices.

I currently use RTT estimates based on information that the
device, AS AN INTEGRATED ENTITY, can gleam from the *set* of
protocols running thereon. (This lets me avoid adding extra
traffic as "overhead" -- low information content per octet).
I.e., instead of explicit acknowledgements (which add overhead),
the acknowledgements are *inferred* from other observable
behaviors in the device as a whole.

While I can get a rather precise metric for the temporal costs
of the *fabric*, I'm having a harder time trying to factor in
the variance in the processing times on the (remote) node
without artificially tightening its deadline constraints.

Specifically, I'm trying to (dynamically) maintain the functional
equivalent of the RTO at the minimum level that *just* catches
a lost datagram without waiting wastefully too long *or*
"correcting/recovering" prematurely.  The algorithms used in
commodity stacks tend to be very naive in their expectations
(of necessity!) so you don't get a finely tuned response.  There,
the cost of a dropped packet is inconsequential.  I want to
dynamically alter the deadline that invokes the "recovery
handler" for these particular protocol instances -- not too soon
(wasted effort as the "dropped" datagram may be arriving *as*
the handler starts running!) nor too late (threatens performance).

I guess this boils down to filters to guesstimate runtimes of
specific (remote!) tasks?

Thx,
--don

[toc] | [standalone]

Back to top | Article view | comp.realtime

csiph-web