Dan Creswell wrote:
So I'm still confused about what the exact use cases here so I'll guess:
One seems related to firewall traversal etc and whether or not callbacks
can performed.
The issue here is that a route from host A to host B can be
fundamentally different than from host B to host A, firewall traversal
is just one example, routing, NAT, proxying, DNS are others I can think of.
If from host A one registers for events for a service at host B and I
succeed it doesn't tell me anything about the ability for the event
producer on host B to send the events to host A. For that reason some
event protocols have their event equivalent 'ping' as an agreed upon
first event.
SARE covers this case in its current specification, something not
covered by 'ping'.
A second appears to be attempting to divine whether or not you've lost
some events.
That really depends upon whether the actual event protocol (JavaSpaces
notify, Lookup Service service discovery event protocol) have the notion
of strictly increasing sequence numbers i.e. no gaps allowed. JavaSpaces
allows for gaps, the Lookup Service spec not. In general an event
protocol that is used to build a state from events will have strictly
increasing sequence numbering.
Given the semantics for SARE to have a sequence number that equals the
last send sequence number you might infer whether you missed an event,
depending on whether the event protocol is strictly increasing.
However the spec with regard to sequence numbers for a SARE has been
chosen mainly for not interfering with the service specific event protocols.
With ping asking about the last event sent I consider more tricky as
there might be an undefined number of events in transit at the moment
the server receives your ping request. The larger the interval becomes
between your decision to ping and the time the server processes 'ping'
will increase the chance you get a positive (false) answer on your
question whether you missed something.
Assuming you want to minimize the number of false request you have to
act upon I think SARE might do a better job here in most cases.
A third appears to be attempting to divine the health of a remote service.
Yes, although I wouldn't use 'divine' here. All conclusions one can
derive from data points in our industry are often best guesses with
those related to distributed computing having the lowest credibility :-)
The only thing I would say is that apparently a QoS aspect I agreed upon
with the service has not been met. Any consequences I derive from that
are really a combination of my knowledge of the client, service,
environment, etc. and the value of that particular event registration.
All kinds of aspects that are not explicit in the service specifications
itself, but when building system you often take into account.
So SARE is nothing more and nothing less as a optional event protocol
that can be multiplexed with existing remote event protocols that in
certain situations makes it for a client easier to make certain
decision. It ain't a silver bullet, but to me it often provides value
compared to what a ping can provide me for reasons I hope were clear in
the previous posting and I mentioned above.
I decided not to respond on the other remarks because I think they are
either too detailed or represent us using different percentages about
the probability of loosing events, etc. Which given our maybe different
experience with distributed system might be true for both of us.
So I hope we (and I also hope others form an opinion) can get to the
point where it is agreed that SARE represent a valuable protocol
enhancement that is general applicable, or that it ain't and that I
should pursue as part of my own toolbox.
--
Mark
