To:
"EPP Provreg" <ietf-provreg@cafax.se>
From:
Alistair.Braden@nominet.org.uk
Date:
Wed, 20 Jan 2010 09:34:38 +0000
DKIM-Signature:
v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Alistair.Braden@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1263980080; x=1295516080; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Alistair.Braden@nominet.org.uk|Subject:=20Re:=20 [ietf-provreg]=20new=20epp=20commands?|Date:=20Wed,=2020 =20Jan=202010=2009:34:38=20+0000|Message-ID:=20<OF4F90223 3.10C743E7-ON802576B1.0031EECE-802576B1.00349C89@nominet. org.uk>|To:=20"EPP=20Provreg"=20<ietf-provreg@cafax.se> |MIME-Version:=201.0|In-Reply-To:=20<20100119185736.GC733 78@shinkuro.com>|References:=20<OF71E004A6.16DF9618-ON802 576B0.005A5684-802576B0.005AB672@nominet.org.uk>=20<C77B5 59F.36DD4%jgould@verisign.com>=20<20100119185736.GC73378@ shinkuro.com>; bh=K50QFqjPuqhslygP/rZkIc5al0SK7JS4AkUZ5dzx/es=; b=PwSL6MCUeXgoE5xMQotydaPHH5oIht+czscbAEKdLnnu9vDTdqs6hW4V fIrqcOfCDHzIhTn3rn4fh8Rg1JjpgxHA5pkGwDtkIax34UWikteLE4zfq RvfkIjdTEUJ+YGP;
DomainKey-Signature:
s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:Subject:To: X-Mailer:Message-ID:From:Date:X-MIMETrack:MIME-Version: Content-type; b=cEopupd1t29quGBVS5FGQ4K6kKFKtTyLjL/ffe2cxh3G/V6uhppDFRMv iX1ulMSiBVryj9YaUn0oXDLcmHLTp3A4OnT/4KLrByQlGEQLMRZ/Zxd/i pgyHf/Kj9ZUlX2k;
In-Reply-To:
<20100119185736.GC73378@shinkuro.com>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: [ietf-provreg] new epp commands?
> Andrew Sullivan <ajs@shinkuro.com> > On Tue, Jan 19, 2010 at 12:27:11PM -0500, James Gould wrote: > > provided a complete list of sponsorship. Unbounded queries via EPP is not > > scalable. > > Why not? It's just an XML document. Why couldn't one have a > mechanism for this? (Whether it's sane is another matter. I'm just > being querulous.) As has been mentioned, we have an EPP implementation of a list command. The email-based system which predates EPP has a similar command, and is routinely used by registrars to retrieve lists of ~1M domain names along with account, host details etc. Registrars migrating to EPP have a reasonable expectation to do the same thing, hence we have implemented it. There were several scalability issues, but the most compelling was that length of the message has to be known before it is sent, so that the 4-byte header can be correctly written. This means that the entire message has to be held in memory (or other storage), which in this case has the potential to be very large. Multiply this size by the number of possible concurrent requests, and you have an obvious hardware problem. Although the 4-byte header clearly has its uses, it prevented us from streaming information through the EPP server to the user - the storage issue disappears if you can retrieve a small number of rows from the database, format them in XML, send them down the socket, and repeat until you have fulfilled the request. This way, the amount of storage needed per connection is bounded above and is no different to a single-domain <info>, which is much easier to cope with. For this and other reasons, we settled for a hamstrung version with a configurable upper bound. This is rather inferior to the equivalent 'less sophisticated' email system but is useful enough, and is rather more efficient, both server- and client-side, than the registrar sending one <info> request for each of their domain names. By comparison, the email-based system does not process concurrent requests, so the maximum storage required is bounded above by the size of our registry, so holding the entire message in memory was never a problem. Also, it does not return XML, so the message itself is a lot more terse. Alistair Braden -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- List run by majordomo software. For (Un-)subscription and similar details send "help" to ietf-provreg-request@cafax.se