On Mon, 6 Oct 2008 11:53:51 +0100
Pedro Melo <[EMAIL PROTECTED]> wrote:

> Hi,
> 
> On Oct 5, 2008, at 2:07 PM, Pavel Simerda wrote:
> 
> > Please look into real world, not idealistic.
> >
> > Servers have sometimes long timeouts (nobody says they can't),
> > don't do
> > any sort of pings (nobody says they must) and many people have  
> > unstable
> > connections, even on ADSL, but much more on wireless, especially
> > when moving aroud.
> 
> IMHO, "pings" are awful. I would much rather have session-reconnect  
> and link-level acks for stanzas. The pair should provide an even
> more resiliant network than "pings" will ever do.

link-level pings, of course.

This is what you might want to do:
1) when you don't get an ack and want to retry last before
disconnection (maybe not useful at all, not sure)
2) when there are no messages for some time at all (acks are correct,
but you don't know anyway)

These pings are to be found in xep-198 together with acks, if it didn't
change from last time I saw it.

> 
> Pings assert only one thing: A stanza reached the server, and
> another was able to get back. You cannot extrapolate any assurances
> of quality what so ever from this.

link-level pings assert a working connection, and indirectly all
previous stanzas (because of TCP underneath). ACKs are better for this
if there are stanzas to acknowledge.

Sure, XMPP-level pings (xep-199) should not be used there.

> Having said that, a link level keep-alive is useful for silent
> network losses, and pings have its place on my toolbox to kick-start
> S2S connections. If I want to send stanzas to a certain domain and I
> don't know if they have a S2S connection available on my server, I
> delay the send until I get back some sort of ping response.

I am sorry for the confusion between link-level (XEP-198) and xmpp-level
(XEP-199) pings.

> > It's a common things to loose messages on Jabber for people with bad
> > connectins. The good thing is that when one comes back, the old
> > resource is kicked (with reason: reconnected) and the user is
> > notified... and after some time, users learn that after other
> > party's "reconnect", they must re-send what they have posted.
> 
> Yes, as I said above, pings are great to kickstart S2S connections.
> 
> Although I think servers should keep S2S connections open while
> there is an active session with a roster item from the remote
> domain....
> 
> 
> > If this is not the case, users become confused and will start to
> > think Jabber is unreliable. And what more, they will rightly do so.
> 
> I agree that reliability is still a problem with the larger XMPP  
> network, specially small servers.

IMO it doesn't depend so much on the scale of the servers. It's that...

1) Broken connection are often not closed early enough (half an hour is
quite usual).
2) When they are still broken but open (from one or both sides),
they're filled with stanzas the senders expect to deliverd or passed to
offline storage or something (handled may be the best word).
3) Such stanzas are not handled as the connection is broken, they're
lost.
4) The sender recieves no error regardles the point where the message
was dropped.
5) He cannot resend it manually nor his client can handle it
automatically.

Some issues are bad, some are even worse :).

I admit that resource-based kicking is an ugly hack that only solves
one specific situation. I would like to cease it with a better
replacement, not without it. There are no more concerns of mine :).

Pavel

> 
> But unwinding the conversation, using the same resource as a session- 
> resume/takeover tool is the wrong way to go about it.
> 
> Even if you reconnect 10 seconds after you lost the first
> connection, you can still loose messages and other stanzas. You need
> a proper session-resume service to deal with that.
> 
> Everything else is like using a sieve to block out the sun: half- 
> measures.
> 
> Best regards,


-- 

Pavel Šimerda
Freelancer v oblasti počítačových sítí, komunikace a bezpečnosti
Web: http://www.pavlix.net/
Jabber & Mail: pavlix(at)pavlix.net
OpenID: pavlix.net

Reply via email to