ip_realy.pl	FAQ

1) Why perl?
2) How do I use this with ftp, or ftp data is not shapeable?
3) I set my bandwidth to a small value, my ip_relay commands no longer work.
4) I set my bandwidth to a small value, why is telnet still jerky?
5) Is it true you can play Quake and download at the same time?
6) Does it work under windows?
7) How can I shape two different data streams to different rates?

1) Why perl?
    - Quick development time. I also wasn't really interested in a highly
efficient packet forwarding application, it is really designed for single
home-user-on-a-modem use. However I tested it on a 486-DX2 66 on 10Mbit
and found that scp chews far more cpu than ip_relay does.

2) How do I use this with ftp, or ftp data is not shapeable?
    - At the moment ip_relay does not intercept ftp PORT or PASV commands,
although it is probably a *reasonably* easy modification to make. I would 
suggest using something like lynx, and setting ip_relay to forward
to your ISP's ftp proxy, and setting lynx's proxy to the ip_relay host.
For arguments sake the ip_relay host is the localhost, then at a shell just:

bash$ ip_relay.pl 8080:proxy.some.isp:8080
  Resolving address (proxy.some.isp)..... 
  .... determined as: 1.2.3.4
Using command line parameters:
  local_port    8080
  remote_addrs  1.2.3.4
  remote_port   8080
  forwarder 99 set.


ip_relay.pl Version: x.x
Copyright (C) 1999 Gavin Stewart

Passive socket setup on 0.0.0.0:8080
>

bash$ export ftp_proxy="http://localhost:8080"
bash$ export http_proxy="http://localhost:8080"
bash$ lynx ftp://yourftp.host.com/path/file.dat

    - and so now lynx downloads through ip_relay.
   (- we are assuming a bash shell, use "setenv" for csh, tcsh).
    - WARNING the version of lynx that comes with the RedHat 5.2 distribution
is broken (lynx-2.8.1) and does not work with proxy servers, try upgrading
to >= 2.8.3-13 (http://....../redhat/contrib/libc6/i386/lynx-2.8.3-13.i386.rpm,
on your nearest RedHat distribution mirror.)

3) I set my bandwidth to a small value, my ip_relay commands no longer work.
    - You set the bandwidth variable too low. ip_relay is a single threaded
application, this has some noticeable drawbacks, one is that if bandwidth is
set < 500 bytes / sec, so much time is spent delaying the packet that the
apparent response time on the prompt is quite slow.

4) I set my bandwidth to a small value, why is telnet still jerky?
    - Lets say you set bandwidth to approx 1500 bytes / sec. The common MTU 
(Maximum Transmit Unit) size for most interfaces is 1500, this leads to 
approx 1500 byte chunk of data being sent down the modem at one second 
intervals. Your telnet (interactive application) packets are being queued 
behind this sudden chunk of data, making it feel latent.

                       Packets in queue.
          +-+ +-+ +-------------------------------------+ +-+
          |T| |T| |     Big download packet.            | |T|
    ------+ +-+ +-+                                     +-+ +--------->

           |   |                                           |
           \---\----< small telnet packets >---------------/

    Can this be fixed?
    - Yes, in different ways, to different degrees depending on your options.

    i) Try setting your MRU (Maximum Receive Unit) lower in pppd, so as to
fragment packets being sent from the remote side of your ppp link. The
remote server you are downloading from is still sending 1500 byte payloads
in its packets, however these will be fragmented to allow your telnet
packets to slip between them. You could try settings from 128 to 500.
(This increases packet header overheads, and may not be the most efficient
 use of available bandwidth.)

                       Packets in queue.
          +-+ +-----------+ +-+ +------------+ +------------+ +-+
          |T| |     Big do| |T| |wnload packe| |t           | |T|
    ------+ +-+           +-+ +-+            +-+            +-+ +--------->
          
           |                 |                                 |
           \--------< small telnet packets >-------------------/

    ii) Put ip_relay on a host on the *other* side of the modem, and set the
data_size variable to a small value (default 500). When bandwidth is limited
enough the forwarding of data units is small enough to produce small TCP
packets, the equivalent of lowering MTU on the server you are downloading from.
In the original example, instead of approx 1500 bytes / sec, you get 
500 bytes / 0.33 sec, leaving much more room for other packets to 
"slip between" the download stream.

                       Packets in queue.
     +------------+    +-+ +------------+    +-+ +------------+ +-+
     | d-load pak |    |T| | d-load pak |    |T| | d-load pak | |T|
    -+            +----+ +-+            +----+ +-+            +-+ +-->
          
                       |                     |                  |
                       \---< small telnet packets >-------------/

5) Is it true you can play Quake and download at the same time?
    - Yes, you need the setup above in 4)ii) where ip_relay runs on a machine
on the *other* side of the modem you are downloading with.
	- Set the data_size variable low, say 80 (bytes).
	- Set the bandwidth variable low, say 500 (bytes).
	- Try your luck, mileage may vary.

6) Does it work under windows?
    - I have never tried it under perl for windows so I don't actually know. I 
have used perl under windows before though, and I imagine it should work, or
at least could with few changes.

7) How can I shape two different data streams to different rates?
    - Run another instance of ip_relay for the other rate.