Gary Barnett writes:
>ObCircle:
> Given the increasing amount of packet loss I have been experiencing, the
>following
> idea presented itself:
>
> 1) Instead of just sending one packet, send a configurable number (1-10)
> 2) Create a special telnet client that will disregard packets with the
> "new" packet number that are duplicates of one's it's seen already.
>
> In essence blast a bunch of packets in the hopes that one gets through.
>
> The question: How would you go about modifying Circle's socket i/o routines
> allow this? Would this _require_ UDP or is there some way to get around the
> standard ack response requirement in order for things to stay
> synced?
For the most part, it is not possible to modify TCP's retransmission
algorithm from the user level (e.g., using setsockopt() calls).
However, some operating systems let you fine-tune various TCP
parameters to optimize them for your particular site. For example,
Solaris has about 30 tunable TCP parameters that are settable using
the "ndd" command. I think Linux lets you tune various TCP parameters
through the pseudo-files in the /dev/tcp directory. So, if you are
root on your machine, and your OS lets you tune TCP parameters, you
can try doing it that way.
Second method (not for the weak of heart): If you're using Linux and
you are a brave kernel hacker, you might be able to modify the TCP
code itself inside the kernel to always transmit each segment multiple
times. But this might not be a good idea (see below).
Now, if you *really* want to come up with an entirely new
transport-layer protocol called MalloryTCP, which is just like TCP
except that it very aggressively tries to transmit everything, yes,
the way to do it would be by switching to UDP. Of course, then
everyone connecting to your MUD would require a special client.
And you'd end up reimplementing everything that TCP does (which is
highly nontrivial!)
However, MalloryTCP is probably not a good idea, because a huge amount
of brain-power has been devoted to refining TCP over the years. Most
recent TCP implementations incorporate TCP fast retransmit and
recovery algorithms that are pretty good at detecting how congested
the network is (i.e. how often packets are lost), and adjusting the
retransmission algorithm accordingly and dynamically. Remember, if
the network is already congested causing packet loss, the *worst*
thing you can do is "compensate" by blasting a billion packets across
the network - then the congestion will just turn into even more severe
congestion.
-Jeremy
PS - If you are trying to understand the mechanics of how TCP works,
the best book (by far) I've ever seen is TCP/IP Illustrated Vol. 1 by
Stevens. It graphically shows how TCP works by examining the output
of 'tcpdump' for various network sessions. It was after I read this
book that I used 'tcpdump' to analyze the output of Circle, and, after
realizing that it was generating unnecessary extra packets, I made
those changes to pl12 that massively reduce the network traffic, as I
described in pl12's ChangeLog. (Did anyone read that?)
PPS - Yet another idea for coping with your congested network is to
upgrade to pl12, if possible. As noted in the PS it generates
significantly fewer packets and therefore will almost certainly
perform better on a congested network.
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 12/08/00 PST