Re: [xmlblaster] New xmlBlaster session handling

[Cyrille Giquello <cyrille at ktaland.com>]

Marcel Ruff a écrit :

> Heinrich Götzger wrote:
> > Hi,
> >
> > the spec. sais:
> > " XmlBlaster allows to check clients with a ping to the callback server.
> > The ping frequency is adjustable at login time by the client itself. A
> > client session disappears when it does a logout or on failure (no response
> > to the ping) or on session-timeout or when killOldSessions=true is set."
> >
> > I'm courius about this, please allow me two questions:
> > Do you have any examples on how this ping-stuff is to be realised in Qos?
> > How many pakets (if at all) may be lost, unless the client will be
> > disconnected?
> >
> > One may not have a high performance netconnection but for example using
> > some radio-net or even letter-doves ;-). If one ping-frame drops out it
> > should not force the connection to shut down.
> > So I could imagine closing this client after 5 lost pings in a row for
> > example. Whereas a successful ping could reset this counter to 0.
>
> This is an interesting issue.
> The current ping is a blocking, application level ping,
> it sends a string and a string is returned.
>
> So there is no difference when invoking update(),
> update sends some arguments and receives a return value.
> (The return value is needed in future to allow
> transaction support with two phase commit).
>
> Loosing pings is dramatic, as is loosing updates.
> If we allow lost pings, we need to allow lost updates
> with resending until we succeed (or a certain number is reached).
> A MoM should support it, but i'm not shure
> if we shouldn't drop the client in such a case,
> and wait until the client reconnects.
>
> Possibly the best solution is to have a configuration
> parameter supporting both philosophies.
>
> Another question:
> -----------------
> Should we add a second update method, say
>
>    oneway updateOneway(MessageUnit[])
>
> which would allow much higher performance since no
> response message is needed with the drawback that this
> mode won't support transaction safety?
>
> Please vote on this.

Hello guies !

I'm voting for that second update method.
In case we want to send messages like UDP fashion. We don't want transaction, but fast and very frequent
update.
I think this is a nice option.

Cyrille.


>
>
> regards,
>
> Marcel
>
> --
> Marcel Ruff
> mailto:ruff at swand.lake.de
> http://www.lake.de/home/lake/swand/
> http://www.xmlBlaster.org

--

 -----------------------------------------
 -      http://www.ktaland.com/
 - Pour votre MAC: http://TOUSOFT.COM/
 -----------------------------------------
 * CONFIDENTIALITY NOTICE
 * The contents of this e-mail are confidential to the ordinary user of the e-mail address to which it
was addressed and may also be privileged. If you are not the addressee of this e-mail you may not copy,
forward, disclose or otherwise use it or any part of it in any form whatsoever. If you have received this
e-mail in error please e-mail the sender by replying to this message.
 -----------------------------------------
Encryption | Duncan Campbell | DST | Blacklisted 411 | ECHELON | 2600 | PGP | Corsica | NSA