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.
"Marty Joel"
<mjoel at netreo To: ipp at pwg.org, ifx at pwg.org
n.com> cc:
Sent by: Subject: IFX> ippget and Lost Events
owner-ifx at pwg
.org
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