Re: Message Pushing and TCP Transport

[Eric Brunner <brunner@nic-naa.net>]

> On Sat, Sep 01, 2001 at 12:29:55PM -0400, Eric Brunner took time to write:
> > >> How many messages are waiting?
> > >
> > > The value of the count attribute.
> > > Reading the draft :
> > >   - An OPTIONAL <msgQ> element containing a "count" attribute that
> > >     identifies the number of service messages queued for client
> > >     retrieval.
> > 
> > So no messages are deleted from or added to the queue subsequent to the
> > (atomic) set of events in which a value is written to msgQ->cnt, and the
> > (atomic) set of events when, to use your original, the registrar "gets
> > them[.] (immediately or later at its convenience)"?
> 
> Imagine the client receive the information : 1 message waiting... but
> another one came at the same time (since this is what you imagine, if
> I understood you correctly).
> The client *think* there is only one *new* message.
> So it does a poll to take it.
> With the result it sees that is another one he was not aware of
> previously. Thus he can do the poll again.

Therefore while the inter-arrival time of enqueuement events (latent pushes)
is equal to the interarrival time of dequeuement events (actual polls), and
one additional enqueuement event occurs between enqueue and dequeue service,
the client continues to poll until no enquement event occurs between enqueue
and dequeue events. Off-by one after a fashion.

If the inter-arrival time of enquement events (latent pushes) is less than
the interarrival time of dequeuement events (actual polls), the client
continues to poll, and the queue grows without protocol-constrained bound.
Resource exhaustion, and as Scott suggested, bulk dequeue and external
transport (or bit bucket).

> Where is the big deal ?

OK.

> BTW also if we take a *real* case (not some sort of pure
> conjectures...) like using those messages for transfers notification,
> they do not came 10000/hour or day either...

The enqueuement is taking place on the registry, taking registry resources,
and potentially at rates unconstrained by network bandwidth or rates of
connection.

> > Just to be sure, and I'll make this my last question to you, how many
> > messages are waiting?
> 
> Trying to make me look stupid has no real value I think.

Non-goal.

> I do not think that the provreg protocol want to define precisely how
> to count how many messages are waiting. I think that no real
> implementation will care about that.  What is important is *if*
> messages are waiting or not.
>
> Let me try to again phrase my position (after that I think this
> thread should be closed), because either I am not clear enough, or
> you do not seem (to want) to see my point :

We're probably just chewing the error-recovery bone. We simply differ
over how tasty it is, and if it is something both a registrar and a
registry need to agree upon.

If it (error recovery) isn't specified, and no one wants to spend time on
failure cases, then we were done some days ago. Failure and restart/resync
are registrar- and registry-private matters, specified external to the work
of this WG.

> People are objecting to the poll because it creates overhead (mainly
> because it needs that clients periodically connect to know if
> messages are waiting, they say).

No. If the overhead of deferred message delivery is a burden, the message
may be dequeued without warning, and delivered by other means (I'm fond of
avian carrier). The form of "overhead" is immaterial. One form is servicing
tight-loop polling, another is servicing non-polling.

> I say it is false since there is no need to do specific polls to know
> if messages are waiting, since the draft is good enough to provide
> this information in *normal* results, ie usual business.

Rates of enqueue and dequeue are not necessarily symmetric, nor smooth.

> Using poll, client has nothing to do. It does its usual business.
> Some times he will be warned that they are new messages. After that
> it is up to it to handle this correctly. This *only* was my point.
> About semantics you will need to see with the author of the draft, it
> is not my concern here.
> 
> For the record, I agree to have the PUSH as a MAY, however I totally
> disagree to say that the POLL is bad and should be replaced by the
> PUSH. The POLL should be a MUST and the PUSH a MAY.

OK. There's more important things to do. You've convinced me that there is
no latent design weakness, or at least none significantly greater than any
others potentially present, in epp, that arise in the deaf-registrar model.

Eric