Re: Multiple TCP/IP servers on one host

Darren Griffiths (agate!!!dagg@ucbvax.Berkeley.EDU)
8 Sep 88 02:46:08 GMT

In article <8809080134.AA05073@ucbvax.Berkeley.EDU> dcrocker@TWG.COM (Dave Crocker) writes:
>There seems to be some convergence on the use of the domain name service
>ip address list, as a means of accessing multiple interfaces (with one
>interface per milking machine) to the same service host. A couple of
>notes, however, have mentioned reliance on a feature that is not
>supported: having the domain name service select which ip address to
>give you, thereby having the DNS do the randomization necessary to give
>Selection of the "correct" IP address must be done by the client (e.g.,
>telnet). The DNS has no way of knowing what use you will put the information
>to and it has no way of distinguishing multiple milking machines from
>multiple connections to different parts (i.e., different networks) on
>an internet.

I have missed some of the recent discussions on this list, so I haven't seen
any of the previous messages you are referring to, but it sounds like you are
talking about something similar to one of my pet nags about routing (I know
there are a lot of different nags about routing, but this is my favorite). In
many cases there are different paths to the same host, either via backup
redundant links or because of longer hops through the network. Usually the
gateways know about these different paths and take the fastest (determined by
the metric) and leave the other path untouched. This other path may be idle
and quite useful, there are two ways of making use of this path.

  1) If the second path was 25% of the speed of the first path then 25% of
      the packets could be sent that way. This would likely mean that
      packets would be arriving in different orders than they were sent but
      if the two end sides were running the Van Jacobsen/Mike Karels code
      I believe this wouldn't be to much of a problem. If they weren't running
      this code you may lose more than you gain due to retransmits.

  2) The second thing that can be done is a little nicer. The gateways could
      look in to the tcp packets and send some of the stuff through one route
      and some through another. For example, SMTP connections do not always
      need to be taking up bandwidth on a high speed link when they could be
      using a slower backup link leaving the high speed connections for
      interactive users. Real people tend to be a lot more impatient than
      computers (although real people are also a lot slower at many things.)


Darren Griffiths DAGG@LBL.GOV
Lawrence Berkeley Labs
Information and Computing Sciences Division

This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:43:14 GMT