[ENet-discuss] UDPX_TIME_OVERFLOW 86400000

[Jim Purbrick]

What's the reasoning behind this value? I would have thought it would be
~4294967295 for a unsigned int wrapping clock.

The reason I ask is that I need to rewrite the clock using our WallClock
time, which returns a double in seconds. In order to convert it to an ENet
style millisecond clock I multiply by 1000, fmod with
std::numeric_limits<int>::max() and then truncate to an integer.

Because I'm using integers, rather than unsigned ints, I expected to have to
change the overflow value to ~2147483647, but the existing value of 86400000
confused me.

> -----Original Message-----
> From: Jim Purbrick [mailto:Jpurbrick at climax.co.uk]
> Sent: 05 February 2004 19:29
> To: 'Discussion of the ENet library'
> Subject: RE: [ENet-discuss] Prioritisation
> 
> 
> 
> > Well, there is some synergy between reliable and unreliable 
> packets. I
> > use reliable packets to measure the RTT (and its variance) of 
> > the connection, 
> > and send out pings regularly to make sure this information is always
> > being collected periodically. 
> 
> This would stay.
> 
> > Abnormal RTTs (either too high 
> > or too low)
> > cause the throttle to move down or up, as appropriate.
> 
> Packet loss would affect send rate as per TCP friendly algorithm.
> 
> > And the throttle
> > basically just tells how many packets to drop. I try to send the
> > unreliable packets out ASAP or drop them, so I basically 
> trade latency
> > for packet loss. Given what ENet was written for, the 
> latency was the
> > way more critical issue.
> 
> My plan would be to keep sending rate and lifetime 
> orthogonal. As well as
> having a per-message priority you would have a time to live 
> for unreliable
> packets. When a packet is taken out of the priority queue to 
> send it's time
> to live is compared with the current time and, if stale, the packet is
> dropped before sending.
> 
> This can result in a build up of messages, but this allows 
> the client to
> respond to back pressure. A maximum time to live for 
> unreliable packets
> would avoid chronic message build up and latency. A point 
> would be reached
> where all unreliable data would be dropped, as with the current ENet.
>  
> > Now, the reliable packets just use a window, which is 
> > probably far from
> > ideal. But on the other hand, it "magically" works with the 
> unreliable
> > throttling as lots of reliable traffic will cause the RTTs to 
> > go up and
> > the throttle will start dropping more unreliable packets in 
> response.
> 
> With a rate based approach packet loss due to internet 
> conjestion would
> result in sending rate lowering in a TCP friendly way, 
> avoiding conjestive
> collapse. With ENet I think what happens is that routers will 
> drop packets,
> causing them to be resent and more unreliable packets to be 
> dropped. As the
> resends back off exponentially and the amount of unreliable 
> data goes down,
> ENet responds in the correct way, as the data rate goes down, 
> but I'm not
> sure if it's TCP friendly.
>  
> > Now, in an ideal world, ENet would probably not work by "magic" and
> > would use some sort of uniform rate based approach, although 
> > I am not so
> > sure it would help the unreliable packet situation and would require
> > either require more info about connection bandwidth or just some new
> > "voodoo" to automatically determine some ideal rate to send 
> > data out at.
> 
> You probe for network bandwidth in a similar way to TCP. You 
> increase data
> rate until you encounter packet loss caused by routers 
> reporting conjestion,
> then slow down the data rate in response to the packet loss. 
> By additively
> increasing data rate, but exponentially decreasing it you ensure that
> conjestive collapse is avoided.
> 
> > In any case a possible start would be to have some good 
> > metric of how much
> > data in total is being sent out over a given time period, 
> and have the
> > throttle attack that, rather than merely unreliable packets. 
> 
> Yep.
> 
> > And I don't
> > know if I would even want to change how unreliable packets 
> > are handled,
> > so much as making something more flexible than the window scheme for
> > reliable data. 
> 
> Don't do anything drastic with ENet. I'll just tinker away and keep
> badgering you with questions and I'll let you know how I get on.
> 
> > Then you start getting into the land of Quality of
> > Service --- UGH! 
> 
> Real QoS can't easily be done over the internet as it's a best effort
> system. You need to be able to reserve bandwidth. What I plan 
> to do is use
> prioritisation to provide Class of Service, so I can ensure that high
> priority traffic gets 80% of my bandwidth - even though the 
> bandwidth might
> constantly change!
> 
> > A choice between magic or voodoo, hmm? :)
> 
> Not really. A choice between TCP-like sliding windows, used 
> to control a
> rate based unreliable service, or a pure rate based system 
> using packet loss
> detection to back off sending rate in the face off conjestion.
> 
> Both eminently do-able.
> _______________________________________________
> ENet-discuss mailing list
> ENet-discuss at cubik.org
> http://lists.cubik.org/mailman/listinfo/enet-discuss
>