[ENet-discuss] ENet for use over wireless networks

[Rene Dudfield]

Sorry no enet answers.

Have you tried turning off nagle with tcp?  Using the socket option TCP_NO_DELAY


Have fun!


----- Original Message -----
From: Pete Diemert <pete_diemert at msn.com>
Date: Thu, 6 May 2004 12:35:37 +1000
Subject: [ENet-discuss] ENet for use over wireless networks
To: enet-discuss at cubik.org









 

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