[ENet-discuss] ENet for use over wireless networks

Lee Salzman lsalzman at telerama.com
Fri May 7 21:11:24 PDT 2004


I don't think the throttle should be a problem. Since ENet measures RTT
improvement as well as RTT degradation. Only if the RTTs were
consistently bad over the measurement interval (which is about 5
seconds) would this have any significant effect on the throttle. And 5
seconds later, the throttle gets a new measurement of the average RTT to
work with. 

The conditions I tried to optimize the throttle for are also
similar to this. I wanted ENet to play well over 56K modems (and Cube
does indeed work awesomely over 56K modems if I do say so myself).
However, modems have a lot of connection "noise" on them, so the
throttle has to be reasonably skeptical about connections getting worse
for it to kick in (i.e. only should really go off if someone starts
downloading some MP3s while they're playing Cube), but it still needs to
be effectively and responsive for those situations. 

So, I think the existing throttling mechanism would do okay. Where it 
would do bad in your setting I think is only those places where it would 
fall down for internet use in general. In fact, ENet seems to work better
on bad connections than it does on very good connections (funny, eh?). 
But I'm working on a new throttle  which I may have done in a month or 
two that should be better. :)

Lee

On Sat, May 08, 2004 at 12:53:57PM +1000, Pete Diemert wrote:
> Lee,
> 
> In light of "handoff" scenarios for wireless can the RTT be calculated as the average within the transmission window ONLY?  It seems to me that this small consideration would also work well in a wireless handoff scenario where several packets will be dropped within a single transmission window (i.e. very close together).  At this point the sudden drop in RTT could then be easily detected and NOT trigger the throttling mechanism for this special case.  This would minimize bandwidth loss in wireless scenarios while still maintaining the same optimization for wired situations.
> 
> pete
> 
> 
> 
> 
>  Lee Salzman wrote:
> The funny thing is, ENet doesn't even use packet loss as an indicator of
> changing network conditions just because it doesn't happen often enough
> to really gauge what's going on. ENet instead uses changes in RTT of
> reliable packets/pings to tweak the throttle.
> 
> Also, ENet can batch all protocol commands into a single UDP packet,
> including acknowledgements. I imagine thsi should be helpful for
> minimizing the amount of cross-talk.
> 
> Other than that I just want to gut the throttling code entirely based on
> a scheme I outlined in an earlier post to the list, can't think of any
> suggestions. :)
> 
> Lee



More information about the ENet-discuss mailing list