|
|
| Author |
Message |
< Ejabberd mailing list ~ s2s and c2s ping/keep-alive and "proper" shutdown |
| Guest |
 Posted: Mon Oct 09, 2006 10:38 pm |
 |
|
|
Guest
|
Peoples,
I was struck by the ranting at http://about.psyc.eu/Jabber and inspired
to fix ejabberd to close sockets correctly
(http://mailman.jabber.org/pipermail/standards-jig/2006-May/011403.html).
Digging into the code, yay, I see that neither s2s nor c2s connections
have any heartbeating beyond tcp timeouts. While efficient this isn't so
hot for saving fd's, giving good user feedback that their friends have
rebooted/coredumped, or closing xmpp connections "correctly". The tcp
defaults are to only send keepalives every 2 hours, the minimum per tcp
recommendations somewhere, changing them isn't always possible or a good
idea.
I see that some servers sent empty (1 whitespace) packets to force tcp
connections to either stay open (ack) or die (no ack after re-xmits).
Also helpful for keeping firewalls alive I guess, but the client can
manage that. I think I'd do that for any connection that hadn't had
traffic in <config> seconds.
As per http://www.jabber.ru/bugzilla/show_bug.cgi?id=275 I'm thinking of
a few options, but I thought I'd mention it here before doing any real
work. It doesn't look hard to add, although I'd like to take the easy
way out for s2s connections.
Cheers,
Bruce
PS I think I'm having s2s problems with jabber.org at the moment (1.11
on my side) where conversations go one sided if I overload the pacing (I
think) by doing a copy/paste. It is pretty repeatable and no (immediate)
error messages result.
_______________________________________________
ejabberd mailing list
ejabberd@jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Oct 10, 2006 4:18 am |
|
|
|
Guest
|
On 10/10/06, Bruce Fitzsimons <Bruce@fitzsimons.org> wrote:
> Peoples,
> I see that some servers sent empty (1 whitespace) packets to force tcp
> connections to either stay open (ack) or die (no ack after re-xmits).
> Also helpful for keeping firewalls alive I guess, but the client can
> manage that. I think I'd do that for any connection that hadn't had
> traffic in <config> seconds.
Sending whitespaces doesn't help much to keep tracking over the TCP
connection. You still rely on TCP timeouts which are quite long
(though not 2 hours as with default keep-alive mechanism).
The only (AFAIK) way to ensure that connection is alive is to send
some packet for which client issue a reply. XMPP doesn't define this
acknowledgment protocol, but it would be much better from the
reliability point of view if all packets were acknowledged in some
way.
--
Sergei Golovan
_______________________________________________
ejabberd mailing list
ejabberd@jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Post recived from mailinglist |
|
|
| Back to top |
|
| Guest |
| Posted: Tue Oct 10, 2006 9:49 am |
|
|
|
Guest
|
Sergei Golovan wrote:
> On 10/10/06, Bruce Fitzsimons <Bruce@fitzsimons.org> wrote:
>> Peoples,
>
>> I see that some servers sent empty (1 whitespace) packets to force tcp
>> connections to either stay open (ack) or die (no ack after re-xmits).
>> Also helpful for keeping firewalls alive I guess, but the client can
>> manage that. I think I'd do that for any connection that hadn't had
>> traffic in <config> seconds.
>
> Sending whitespaces doesn't help much to keep tracking over the TCP
> connection. You still rely on TCP timeouts which are quite long
> (though not 2 hours as with default keep-alive mechanism).
>
Hmm. I agree. I really like SCTP (in my day job) because of this since
frequent heartbeats are part of the protocol. Closing sockets based on
msiing TCP ACKs may be marginally better timewise (linux quotes
13-30minutes, as standard) but I agree it isn't worth doing unless it is
radically improved.
Reading further into the list I see this has been discussed a lot more,
and without many conclusive results. I'm somewhat stunned that an
application protocol really believed that TCP was reliable end-to-end. I
guess it comes back to the design goals -- is 99.n% reliability
w/blackholing good enough?
> The only (AFAIK) way to ensure that connection is alive is to send
> some packet for which client issue a reply. XMPP doesn't define this
> acknowledgment protocol, but it would be much better from the
> reliability point of view if all packets were acknowledged in some
> way.
>
Yes. JEP/XEP-22 does sort of define this, but at quite a cost (client
impl, and network bandwidth). It also isn't really designed as an
ack/resend type thing, just a friendly status report that itself is
unreliable 
Okay, so I'll have more of a think about this. The tcp queue length vs
sent bytes thing (
http://mail.jabber.org/pipermail/standards-jig/2003-December/004570.html
) could be done in erlang (under linux at least, breaking
multi-platform). This would give more reliability, but not absolute
reliability. s2s in SCTP would be great, even if not standardised, I
wonder when that SCTP impl will make it into OTP?
Thanks,
Bruce
_______________________________________________
ejabberd mailing list
ejabberd@jabber.ru
http://lists.jabber.ru/mailman/listinfo/ejabberd
Post recived from mailinglist |
|
|
| Back to top |
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
