Re: Support of FQDN for Polygraph 2.5.4

From: Alex Rousskov (rousskov@measurement-factory.com)
Date: Tue Feb 27 2001 - 10:21:30 MST


On Tue, 27 Feb 2001, Craig Brown wrote:

> Is there any chance of a pre-release ?

Not a chance! The polygraph-2.6.0b5.src.tgz sources are, however,
available at http://polygraph.ircache.net/sources/tars/

Please note that we do not want to provide support for the beta code.
I have attached some DNS-related discussion below, but if you get
stuck we may not be able to help until 2.6.0 is released.

Please report all bugs to polygraph-bugs rather than this list.

Good luck,

Alex.

----------- random DNS-related comments -----------------------

This is an unofficial, undocumented distribution.

Polygraph will attempt to resolve FQDNs run-time by sending queries to
a specified DNS resolver. No other resolution method is supported.
Polygraph does not come with a resolver, but there are many good real
resolvers available (e.g. bind). You will need to know how to
configure your own DNS resolver to resolve FQDNs you use during the
tests.

A few changes to your PGL files are required to support domain names.
Here are the rules you need to follow:

    0. Use one configuration file for all Polygraph agents
       (this requirement is not new, but it is becoming more
        and more important).

    1. Robot's and Server's hosts fields must use IP addresses
       as before. This is not a limitation, but a reasonable
       requirement if you think about it. Polygraph must know
       where to start/bind robots and servers.

    2. Robot's origin field may use domain names.

    3. Robot's should have DNS resolver configured via
       dns_resolver field. See below for examples.

    4. If domain names are used in (2) an "address map" must
       be provided and use()d. See below for explanation and
       examples.

    5. DNS resolver talks to the specified DNS servers only.
       It does not check /etc/hosts table or /etc/resolv.conf
       file. While this may be considered as a limitation,
       supporting /etc/hosts and /etc/resolv.conf will not be
       possible on all platforms (think Windows) and is not
       appropriate for most benchmarking purposes -- Polygraph
       should stay away from local "host" configuration, it
       should simulate "hosts" that may have nothing to do
       with the local environment. A PGL alternative to
       /etc/hosts and /etc/resolv.conf may be provided at a
       later time.

    6. A few data structures still need to be optimized for speed
       and RAM usage. You might not be able to test large
       configurations with the current code.

DNS Resolver
------------

  You need to tell Robot how to resolve FQDNs. A Robot has a
  "dns_resolver" field of "DnsResolver" type for that purpose:

    DnsResolver DnsRes = {
        servers = [ '127.0.0.1' ]; // DNServers to send queries to
        timeout = 5sec; // query timeout
    };

    Robot R = {
        ...
        dns_resolver = DnsRes;
    };

  Or, simply

    Robot R = {
        ...
        dns_resolver.servers = [ '127.0.0.1' ];
        dns_resolver.timeout = 5sec;
    };

  Naturally, DnsResolver is similar in purpose to the
  /etc/resolv.conf file.

  The resolver was tested with two recent versions of bind only. It does no
  caching and uses the first IP address if many IP addresses are returned.

Address Map
-----------

  For numerous reasons, Robots need to know what Servers they are
  talking to. When origin servers are specified using FQDNs, it may take
  a lot of time to match hundreds of domain names and IP addresses at
  startup. For this and other reasons, you must assist Polygraph in
  matching "names" with IP addresses:

    AddrMap map1 = {
            addresses = '192.168.0.1-10:8080';
            names = 'host[1-10].tmf.com:8080';
    };
    ...
    use(map1);

  Many non-overlapping maps can be use()d in one experiment. The "names"
  field in an AddrMap object may contain IP addresses. The "addresses"
  field must contain IP addresses only.

  Currently, only 1:1 mapping is supported. An unmapped name maps to
  itself by default (it has to be an IP address in that case, of course).

  Address maps are actually handy for specifying Robot and Server
  configuration later on:

    S.hosts = map1.addresses; // must be IPs!
    R.origins = map1.names; // may be FQDNs
    R.hosts = ['127.0.0.1' ** 10 ]; // unrelated to mapping

  Do not forge to use() the maps you are using.

  Needless to say, your DNS server should be able to resolve the
  names used in your PGL file.

More examples
-------------

. I have attached a small gzipped archive with simple but working
  PGL and named configuration files in case I missed some details
  above. Those files has not been checked against 2.6.0b5 and
  may be out of date.





This archive was generated by hypermail 2b29 : Tue Jul 10 2001 - 12:00:17 MDT