[ENet-discuss] ENet for use over wireless networks

[Lee Salzman]

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

On Thu, May 06, 2004 at 12:35:37PM +1000, Pete Diemert wrote:
> 
> Hello,
> 
> This is not so much an explicit question but rather a open query to elicit some useful insight into ENet.  Understanding that ENet was originally designed as a protocol layer for sending video game data (i.e. bursty, lossy, low latency) we have actually found that the same library works well for our scenario which is entirely different, database synchronization over LAN and wireless networks (GPRS, GSM, 802.11, etc..).  We decided to use ENet primarily for two reasons:
> 
> 1) high scalability  - we may want to have many (e.g. >1000) clients synchronizing with our server simultaneously.
> 2) UDP protocol support - we need the option of fine tuning packet transmission to a much greater extent than is available using TCP socket options.
> 
> The reasoning behind #1 is obvious but the requirements for #2 came about mostly due to some research into the dynamics of wireless networks.  The key differentiators of wireless networks seem to be a) packet traffic is MUCH more expensive (both literally and figuratively) and b) packet loss in many cases is NOT due to congestion but rather due to known wireless network artefacts such as "handoff" (cell switch, momentary connection drop) and high bit error rate (BER).  So, obviously, TCP connections can cause major headaches over wireless connections due to both the "chatty" nature of the protocol and the standard (Reno) re-transmit algorithm which ASSUMES network congestion on packet loss thereby immediately cutting bandwidth to resolve the issue rather than selectively retransmitting based on the actual cause of the packet loss (techniques floating around like SACK, SNOOP, protocols based partly on Explicit Loss Notification (ELN)).
> 
> Which brings me back to ENet and my questions:
> 
> -  What are some techniques we can use to reduce packet traffic over ENet when a connection is not actively transmitting but will not impede maximum bandwidth use while streaming (i.e. simply increasing timeout may help the former but not help the latter and even the "average" transmit time may need to be quickly increased to maximize efficiency)?
> 
> -  Without a loss notification system at the router to know whether a lost packet was due to congestion are there some other techniques which can improve throughput over ENet when packet loss is due to a momentary drop in connection?  (perhaps just a flag on the connection itself stating "I am a wireless connection, please don't use the standard throttling mechanism for packet loss when several drops occur in the same transmission window")
> 
> Any insights or comments are greatly appreciated,
> Pete Diemert
>