IPP Mail Archive: IPP> Re: IFX> ippget and Lost Events

IPP Mail Archive: IPP> Re: IFX> ippget and Lost Events

IPP> Re: IFX> ippget and Lost Events

From: Carl Kugler (kugler@us.ibm.com)
Date: Tue Aug 14 2001 - 13:18:21 EDT

  • Next message: Hastings, Tom N: "IPP> NOT - Clients shouldn't use persistent connections for more than 2 connections to the same server"


    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


    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.

                        "Marty Joel"
                        <mjoel@netreo To: ipp@pwg.org, ifx@pwg.org
                        n.com> cc:
                        Sent by: Subject: IFX> ippget and Lost Events
                        09:58 PM


    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

    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.


    Marty Joel

    This archive was generated by hypermail 2b29 : Tue Aug 14 2001 - 13:50:03 EDT