Re: Message Pushing and TCP Transport

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

>  ... the msqQ element of the <result> item of *any* command
> tells him how many messages are waiting.
> (see 2.5 of the EPP draft)

From Sec. 4 Formal Syntax, Sub 1. Base Schema
(Note: <qDate> added in the -03 to -04 delta)

    <complexType name="msgQType">
      <sequence>
        <element name="qDate" type="dateTime"
         minOccurs="0" />
      </sequence>
      <attribute name="count" type="unsignedLong"
       use="optional" default="0"/>
    </complexType>

An unsigned long type holds the type-bounded number of enqueued messages.
A dateTime type holds the temporal identifiers of message enquements. 

There is no guarantee that the value in the long and the ordinality
of the dateTime sequences are equal.

Restated, there are N enqueued messages, and M temporal identifiers,
in a msgQ element. M may be equal to, or less than, or more than, N,
and the M temporal identifiers need not be unique, or ordered.

Finally, the msgQ element's value is associated with a command, having a
fixed momentary value.

The atomicity of EPP operations does not necessarily extend the semantics
of the msgQ values to the acutal enquements between commands, that is, it
is not a sychronization primitive between queue reader and writer threads.

I'm sorry to be so long winded, I agree with your observation _most_ of
the time. I wish I could agree with it _all_ of the time.

> There is no overhead : the client does its usual business stuff
> (that is : it does NOT use the POLL command). 
> Sometimes, as a result of whatever command, the server (Registry)
> will tell him it has some messages in queue.
> *Then* the Registrar does the poll to get them. (immediately or later
> at its convenience).
> 
> The point is that the client has *never* to send a specific command
> to know if messages are waiting. This information (the number of
> messages) is pushed (!) by the Registry with the result of a command.

I'd like to gently suggest that you simply need to add "approximate"
to your first parenthetical remark, and point out that subsequent fetch
of the (approximate) number will return the same, or perhaps a slightly
different number of messages, if it returns all of the messages enqueued 
at the moment the client-originated fetch is server-serviced. It might,
in the "at its [the client] convenience" mode of your example, return fewer
messages than the given value, as dequeue and alternate delivery are still
an option for the server.

> In that setup I see no problems of scale.

I'm going fishing, exact weights and measures are such a drag, and as a
registry operator, I don't have to panic if the transactions you loose
are yours. It shouldn't happen very often, and I guess I can always rate
throttle you if your attempt to limit the proximal variations cause me
to tend towards reduced good-put due to poll-boundedness.

Eric