IETF Logo Mail Archive

Re: Transport requirements for DNS-like protocols

Patrik Fältström <paf@cisco.com> Fri, 28 June 2002 12:30 UTC

Return-Path: <ietf-irnss-errors@lists.elistx.com>
Received: from ELIST-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00A041E5AR@eListX.com> (original mail from paf@cisco.com); Fri, 28 Jun 2002 08:30:05 -0400 (EDT)
Received: from CONVERSION-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00A011E5AP@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Fri, 28 Jun 2002 08:30:05 -0400 (EDT)
Received: from DIRECTORY-DAEMON.eListX.com by eListX.com (PMDF V6.0-025 #44856) id <0GYF00A011E5AO@eListX.com> for ietf-irnss@elist.lists.elistx.com (ORCPT ietf-irnss@lists.elistx.com); Fri, 28 Jun 2002 08:30:05 -0400 (EDT)
Received: from ams-msg-core-1.cisco.com (ams-msg-core-1.cisco.com [144.254.74.60]) by eListX.com (PMDF V6.0-025 #44856) with ESMTP id <0GYF002LP1DZF3@eListX.com> for ietf-irnss@lists.elistx.com; Fri, 28 Jun 2002 08:30:04 -0400 (EDT)
Received: from xbe-lon-303.cisco.com (xbe-lon-303.cisco.com [64.103.98.22]) by ams-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id g5SCS5WG026862; Fri, 28 Jun 2002 14:29:00 +0200 (MET DST)
Received: from xfe-ams-302.cisco.com ([144.254.75.89]) by xbe-lon-303.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 28 Jun 2002 13:29:07 +0100
Received: from [10.0.1.100] ([144.254.74.55]) by xfe-ams-302.cisco.com with Microsoft SMTPSVC(5.0.2195.4453); Fri, 28 Jun 2002 14:29:06 +0200
Date: Fri, 28 Jun 2002 14:11:18 +0200
From: Patrik Fältström <paf@cisco.com>
Subject: Re: Transport requirements for DNS-like protocols
In-reply-to: <20020628034133.D50C518AC@thrintun.hactrn.net>
To: Rob Austein <sra@hactrn.net>, ietf-irnss@lists.elistx.com
Message-id: <15430645.1025273478@localhost>
MIME-version: 1.0
X-Mailer: Mulberry/2.2.0 (Mac OS X)
Content-type: text/plain; charset="us-ascii"
Content-transfer-encoding: 7bit
Content-disposition: inline
References: <199812050411.UAA00462@daffy.ee.lbl.gov> <vern@ee.lbl.gov> <20020628034133.D50C518AC@thrintun.hactrn.net>
List-Owner: <mailto:ietf-irnss-help@lists.elistx.com>
List-Post: <mailto:ietf-irnss@lists.elistx.com>
List-Subscribe: <http://lists.elistx.com/ob/adm.pl>, <mailto:ietf-irnss-request@lists.elistx.com?body=subscribe>
List-Unsubscribe: <http://lists.elistx.com/ob/adm.pl>, <mailto:ietf-irnss-request@lists.elistx.com?body=unsubscribe>
List-Archive: <http://lists.elistx.com/archives/ietf-irnss/>
List-Help: <http://lists.elistx.com/elists/admin.shtml>, <mailto:ietf-irnss-request@lists.elistx.com?body=help>
List-Id: <ietf-irnss.lists.elistx.com>
X-OriginalArrivalTime: 28 Jun 2002 12:29:07.0015 (UTC) FILETIME=[656E3570:01C21E9F]

--On 2002-06-27 23.41 -0400 Rob Austein <sra@hactrn.net> wrote:

> It's not a big deal for the server to perform the entire
> query operation again.

...given the matching operation is cheap. I.e. what you don't say
explicitly is that we should use as much as possible of the CPU on the
client side.

This is one of the reasons why I when I came up with IDNA want the client
to do the normalization etc, so the server can do bitwise comparison which
make handling of hash tables easier.

I am very nervous when people come up with protocols where the client can
pass whatever constraints to the server, and request the server to do
complicated things. Things which is easy when you have an MySQL database
with 100 records, but, when you have more data in the database than what
fits in primary memory, then you loose.


   paf -- with tons of experience regarding "hitting the wall" regarding
          implementation of databases etc

v2.23.0 | Report a Bug | By Email