IFX Mail Archive: RE: IFX> ippget and Lost Events

RE: IFX> ippget and Lost Events

From: Hastings, Tom N (hastings@cp10.es.xerox.com)
Date: Tue Aug 14 2001 - 18:45:38 EDT

  • Next message: Scott Foshee: "RE: IFX> TIFF contact person at Adobe"

    Carl and Marty,

    So having the Printer return the upper and lower bound, means that a Printer
    that has long periods of non-responsiveness can have a bigger difference,
    than a more responsive one? Here are the two operation attributes from the
    2/2/2000 spec:

    "minimum-time-interval" (integer(0:MAX)):
    The value of this attribute is the minimum number of seconds that SHOULD
    elapse before the client performs this operation again for these
    subscription-ids. A client MAY perform this operation at any time, and a
    Printer MUST respond with all pending Notifications. A client observes this
    value in order to be a "good network citizen".

    "maximum-time-interval" (integer(0:MAX)):
    The value of this attribute is the maximum number of seconds that SHOULD
    elapse before this client SHOULD issue this operation again for these
    subscription-ids. A Printer MUST preserve all Notifications that occur for
    the number of seconds specified by this attribute starting at the time it is
    sent in a response. A client MAY perform this operation at any time, and a
    Printer MUST respond with all pending Notifications. If a Printer receives
    this operation after this time interval, it SHOULD have discarded some
    Notifications since the last response.

    Tom

    -----Original Message-----
    From: Carl Kugler [mailto:kugler@us.ibm.com]
    Sent: Tuesday, August 14, 2001 10:18
    To: Marty Joel
    Cc: ifx@pwg.org; ipp@pwg.org
    Subject: Re: IFX> ippget and Lost Events

    Marty-

    I don't think you've solved the problem. You still can't predict how long
    it will take for the connection to be reestablished, and there is still a
    limit to how long an event will be retained, so you can still lose events.
    You can't beat the backhoe-through-the-network-cable scenario with
    protocols.

         -Carl

    P.S. An earlier version of this spec
    (ftp://ftp.pwg.org/pub/pwg/ipp/new_NOT/ipp-notify-poll-000202.doc) had
    minimum and maximum event lifetimes.

    From: "Marty Joel" <mjoel@netreon.com>
    To: ipp@pwg.org, ifx@pwg.org

    cc:

    Subject: IFX> ippget and Lost Events

    08/13/2001

                        09:58 PM

    Hello,

    I'm concerned that in the non-wait mode of Get-Notifications, events could
    be lost. The problem lies in the fact that the sender is unable to always
    predict how long it will take to connect to the receiver, or how long it
    will take once it connects for the receiver to process the request. The
    sender knows how long the receiver takes before deleting events, so it
    knows it must connect and have its request get processed before that number
    of seconds, but connection times may vary, as may printer responsiveness
    due to load.

    The following is not a proposal, so much as it is a possible solution to
    the lost event problem, and is intended to lead to discussion.

    If there was a one-to-one relationship between subscriptions and senders,
    then the receiver could keep events for a long period of time, and delete
    them once they have been retrieved. The problem is when there are multiple
    senders who want to receive the same events. Because subscriptions can be
    created when a job is created, a second sender who wants the same events
    couldn't create a subscription soon enough to not lose per-job
    subscriptions.

    If the receiver knew how many senders there were for each subscription, it
    could keep track of how many senders received an event, and delete the
    event once all senders have received it. If the event contained a list of
    the senders, and they were uniquely identified, not only could the event be
    deleted once all senders have received it, but this could solve the
    duplicate event problem. Maybe instead of a lifetime value, there should
    be a minimum and a maximum lifetime value. An event would live until its
    minimum lifetime even if all senders that have registered for that event
    have already received the event. This would allow a new sender that also
    wants to receive that event to be able to. An event would live no longer
    than its maximum lifetime value. This way, if a sender lost interest, the
    event will still get deleted. I'm sure we would want to dictate some
    minimum value for the minimum lifetime value, and suggest some minimum
    difference between the minimum and maximum lifetimes.

    Regards,

    Marty Joel



    This archive was generated by hypermail 2b29 : Tue Aug 14 2001 - 18:46:28 EDT