Re: Lists and EPP

On Thu, Jun 9, 2011 at 1:42 PM, Jothan Frakes <[email protected]> wrote:
> I like that Jan had an Idea about walking the report, but I'd suggest
> that it would still place a burden on the EPP communications in the
> case of Jim's jumbo jumbo data packet example.
>
> It really shouldn't impact the other users to have such a report
> happening, and I could still see that our jumbo jumbo example would
> place additional load on the EPP server, and there's a matter of
> maintaining state from TRID to TRID on the client side and server
> side, so it might even be more fugly of a solution than just pushing
> the whole thing in one response.

When I put my "transactional hat" on, there's a whole lot of ugly there:
- If EPP generates a "jumbo jumbo" packet, that induces largeness in
several places:
  1.  Large, long-running transaction against database, which DB guys
hate for pretty well-understood reasons.
  2.  Very large data packet that crosses the network
  3.  Large amount of network bandwidth is used
  4.  Very large packet of data that needs to be processed by the
client (e.g. - what if there's 17GB of XML needing to be parsed?)

- If EPP has protocol added to split this into more "bite-sized"
chunks, complexity is induced, as we need to have multiple commands
issued, that do partial processing
  1.  If there's a database, one of two things happen:
     a) If a transaction is held open, you wind up with the same
large-long-running transaction, and perhaps it runs longer
     b) If there's a new transaction per request, consistency between
"chunks" is problematic
  2.  The data packets may be of more reasonable size, individually, but...
  3.  There's still a very large amount of bandwidth used.  This part
is invariant.
  4.  Individual data packets are smaller, so more manageable to
clients, but they have a bigger problem in synchronizing them at the
end.

That seems to capture the ugliness pretty well.

> What about using EPP to trigger a report generation and having the
> response contain either a URI to that report or a response token that
> allowed a poll message to retrieve that report URI upon the completion
> of it being generated?  Perhaps even a poll message that generally
> contains a list of the reports available in its response?

I like that idea quite a bit; I think Andrew Sullivan was the first
one to mention it, upthread.

It allows pushing the problems to different places, and I don't think
this is just a matter of us all fooling ourselves into imagining that
it looks better.

It's a very common pattern to say "OLTP system only does OLTP,
Analytics are done elsewhere."

> Then that data could be retrieved from an out of band process which
> would not place undue burden on the networks, and it could easily
> retrofit to existing implementations.

I suspect that there have been enough workarounds going around that
some registrars may have accustomed themselves to not using the poll
queue facility.  *Some* care needs to be taken so that the poll queue
doesn't become the scary, fragile component that induces the next
round of complaints.
_______________________________________________
provreg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/provreg