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