<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1264" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Hello,</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>This is not so much an explicit question but rather a open
query to elicit some useful insight into ENet. </FONT><FONT
size=2>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:</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>1) high scalability - we may want to have many (e.g.
>1000) clients synchronizing with our server simultaneously.</FONT></DIV>
<DIV><FONT size=2>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.</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>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)).</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Which brings me back to ENet and my questions:</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>- 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)?</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>- 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")</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2>Any insights or comments are greatly appreciated,</FONT></DIV>
<DIV><FONT size=2>Pete Diemert</FONT></DIV>
<DIV><FONT size=2></FONT> </DIV>
<DIV><FONT size=2></FONT> </DIV></BODY></HTML>