Re: Message Pushing and TCP Transport

[Daniel Manley <dmanley@tucows.com>]

Eric Brunner-Williams in Portland Maine wrote:

>Dan, Peter, and Chris,
>
>If your issue is process, then please direct your remarks to the Chairs, and
>to the process issue. Your claim must of necessity be that at some point the
>chairs did find that "rough consensus" existed for poll-only state management.
>
No process issues here.

>
>I don't mind being on the "loosing end" of whatever happens, we just pick up
>our EPP extension drafts (in the I-D Administrator's queue this week) and put
>them back into XRP-is-a-compeating-protocol format, and take our chances with
>the process. May the better draft(s) win.
>
<snip> ... </snip>

>
>Fundamentally there are three parties, the winning and loosing registrars
>and the registry. The winning registrar initiates the transfer. The problem
>to be solved is how the change of state in the registry is communicated to
>the loosing registrar. Numerous mechanisms exist. Fundamentally all the "poll"
>mechanisms require some temporal guarantee that the transfer will not take
>place until a poll-timer has expired. This requirement is absent where state
>change notification may be initiated by the holder of the changed state. 
>
I agree.  Reasonably thinking here, many new registries will likely 
imitate the Verisign RRP registry for com/net/org domains (imitation is 
the sincerest form of flattery, right :).  Afilias' .info registry, I 
believe, will be using a 5 day waiting period.  They are also 
encouraging registrars to use the "poll" for the dual purpose of message 
retrieval and connection pinging, as the RRP 'describe' command is often 
used.  If a registrar isn't going to poll within a 5-day period, then 
it's likely that they won't poll at all and the registry will probably 
contact them to say that they are not following the guidelines set forth 
in the registrar certication test.

Now, I understand that the .biz registry is considering forgoing the 
transfer wait period with the reasoning that the auth info from the 
registrant is enough to consider the transfer ligit.  So a pushed 
notification would be simply be "hey, you just lost a domain" anyway -- 
no delivering timing issues there.

>
>
>One common implementation mechanism is a hold-down timer, the other is a
>listen process. Both are the subject of first-year programming curricula at
>technical colleges. Neither are particularly complicated.
>
Multi-threaded listening processes in first year???

Here's an implementation I've seen (post-university):

Open a TCP socket and share between two or more threads.  One thread is 
always listening and queuing received messages internally.  The other(s) 
send(s) requests to the server.  After a request is sent, the sender 
looks at the received messages queue checking for a response with a 
matching transaction id.  When it finally appears, take the response and 
react accordingly to it.  Also some other thread has to periodically 
wake up and take care of async notifications that might have arrived.

vs.

Open a single socket.  when there is something to pass along, sent it 
over the socket.  now wait for the first reponse.  When it comes, react 
to it.  If some time has past since the last time you did something, 
then go to the server to retrieve any notifications. (no shared 
resourses to worry about, no multi-threading required)

>
>
>When we look to "advantage" of one mechanism over the other, we need to look
>beyond the single-instance transaction. Scott clearly anticipated this in
>draft-ietf-provreg-epp-04.txt, 2.9.2.3 EPP <poll> Command.
>
>If we [servers] (para 2)
>	operators SHOULD consider time-sensitivity and resource management
>	factors when selecting a delivery method for service information
>	because some message types MAY be reasonably delivered using non-
>	protocol methods that require fewer server resources.
>
>and if we [servers] (para 3)
>
>	"MAY implement other mechanisms to dequeue and deliver messages
>	if queue maintenance needs exceed resource consumption limits.
>
>then push is at least as good a mechanism as going out-of-band, or dropping
>the transactions on the floor. Personally I consider either of the latter
>non-solutions, or errata to an incomplete protocol specification.
>
Having the registry purge old/expired notifications and bulk emailing 
them to the registrar isn't such a bad idea.  The registrar (a human in 
this case) would look at the first report of that kind and think, "Gosh, 
look at all the important messages we're missing, maybe we should poll 
like the EPP spec says we should."

>
>
>Design and implementation of a per-registry out-of-band notification handler,
>or a per-registry silently discarded transaction discovery rule, appear to be
>interesting technical challenges.
>
>Broadly, we're looking at the scaling properties of the protcol, as the
>volume of transaction increases, and as the volume of transaction participants
>increases, and not the single-transaction instance.
>
I don't quite understand what you are saying here.  Polling isn't 
scalable?  How?

>
>
>The planned (and unplanned) maintenance events don't have a state change
>initiator corresponding to a "winning registrar", and the "watch service"
>from our (specification) perspective is a random interrupt generator. Both
>affect one or more registrars per event.
>
>
>
>The billing events may be predictable from the concerned registrar, thus
>amenable to registrar-initiated discovery via poll, but there is no real
>guarantee that a registrar's finances are well-known, even to the registrar.
>Quite a few complicated business rules concerning reserves, margins, and time
>are known to exist
>
Wether these come through the registry via push or pull, we'll probably 
just end up emailing a system administrator and that person will have to 
be diligent enough to check their email (i.e. "poll" their account).

>
>
>How do you propose to solve these?
>
Again, pardon the injection of "process" here, but I think it comes down 
to the deciding people evaluating the two and picking one (of course, if 
I've got the process all wrong here then just ignore that sentence).  I 
don't think it would be good for the protocol to give registries and 
registrars the choice, because then some registries might not want to 
give the choice (because of the extra development work involved, or 
personal philosophies) which means the developement of heterogeneous 
registry agents by registrars (what the defunct list, [1], was trying to 
avoid all along).

I'm a geek.  I'll be the first to admit it.  Pushing is cool, but time 
is money.  Registries want to get their systems up and running and 
stable as soon possible so that registrars can get their system up and 
running as soon (and simply) as possible so they can start selling domains.

>
>
>If its technical, to me. If its process, to the chairs, and _not_ to me.
>
>Eric
>
>[1] defunct since 1 May.
>