[jitsi-dev] Access to the XMPPConnection from the Plugin


#1

Hi All!

We’re going to create a plugin for Jitsi to improve user experience of
Jabber protocol.

Our plugin will implement acknowledgment of all outgoing messages that
received by server.

We are faced to losing outgoing messages, in case of local network
malfunction. In these cases real network connection is not working, but
Jitsi keep it's connection online till keep-alive timeout occurs.

In this time window all outgoing messages are lost without any warning.

Only when timeout event occurs, and Jitsi obtains a connection lost status
- the warning shows and describes that this outgoing message can not be
delivered. But all messages before this last message was already lost
without any warning.

The plugin will partially implement XEP-198 (without session resumption,
but this XEP allows it) and improve behavior on servers without XEP-198
support.

Due to the the fact that the lost messages can be life threatening, our
plugin will implement this algorithm (when activated):

-Plugin will buffer the all outgoing messages and then confirm an
acknowledgment from the server.

-If server support XEP-198 Stream Management, the plugin will ask an
acknowledgment of all outgoing messages from the server according to
XEP-198. After acknowledgment is recieved - this message will be deleted
from the buffer.

-If server does not support XEP-198, the plugin will make attempt to ping
server with XEP-199 ping request after the message was sent. On any server
answer (pong or error "not implemented") - the message will be deleted from
the buffer.

-Plugin will resends all the messages in the buffer (in case if it is not
clean) on all Jabber events of Reconnect (REGISTERED).

-Plugin will saves outgoing buffer on application close and restores in
state on starting.

We have already tested this algorithm by hardcoding it in Jitsi source code
of the test build. Everything is fine and works properly.

For now we want to create an separate plugin to community and publish it in
the right way, without modification of the Jitsi's core sources.

But faced a big problem:

Our plugin requires XMPPConnection object of all Jabber's service providers
to adding several Packet Listener.

This object applicable only to ProtocolProviderServiceJabberImpl class
(getConnection method). But it's not accessable from plugin module.

All the tries to import this class is not working coz there is no packages
that exports it.

The one way to import it from a plugin - to add a string

Export-Package: net.java.sip.communicator.impl.protocol.jabber

in
/jitsi/src/net/java/sip/communicator/impl/protocol/jabber/jabber.provider.manifest.mf

We believe that the way of making these changes directly in the
implementation of the protocol is absolutely incorrect, and the only right
one - to build this algorithm in a separate plugin, perhaps attached to the
product distribution.

In this way, we ask you to make these changes in the manifest file, so that
we can continue to improve the Jitsi project. Or at least we're waiting of
advice from you.

Thank You.

Dmitry.


#2

Hey Дмитрий,

It would be great to limit such posts to once per mail.

More inline.

Hi All!

We’re going to create a plugin for Jitsi to improve user experience of
Jabber protocol.

Our plugin will implement acknowledgment of all outgoing messages that
received by server.

We are faced to losing outgoing messages, in case of local network
malfunction. In these cases real network connection is not working, but
Jitsi keep it's connection online till keep-alive timeout occurs.

In this time window all outgoing messages are lost without any warning.

Only when timeout event occurs, and Jitsi obtains a connection lost
status - the warning shows and describes that this outgoing message can
not be delivered. But all messages before this last message was already
lost without any warning.

The plugin will partially implement XEP-198 (without session
resumption, but this XEP allows it) and improve behavior on servers
without XEP-198 support.

FWIW, XEP-0198 is mostly meant for acknowledgements from the remote party. The connection between the XMPP client and server is TCP, which gives you everything you need to determine whether a specific message has been received by the server.

Due to the the fact that the lost messages can be life threatening, our
plugin will implement this algorithm (when activated):

-Plugin will buffer the all outgoing messages and then confirm an
acknowledgment from the server.

Same comment.

-If server support XEP-198 Stream Management, the plugin will ask an
acknowledgment of all outgoing messages from the server according to
XEP-198. After acknowledgment is recieved - this message will be deleted
from the buffer.

-If server does not support XEP-198, the plugin will make attempt to
ping server with XEP-199 ping request after the message was sent. On any
server answer (pong or error "not implemented") - the message will be
deleted from the buffer.

-Plugin will resends all the messages in the buffer (in case if it is
not clean) on all Jabber events of Reconnect (REGISTERED).

-Plugin will saves outgoing buffer on application close and restores in
state on starting.

We have already tested this algorithm by hardcoding it in Jitsi source
code of the test build. Everything is fine and works properly.

For now we want to create an separate plugin to community and publish it
in the right way, without modification of the Jitsi's core sources.

But faced a big problem:

Our plugin requires XMPPConnection object of all Jabber's service
providers to adding several Packet Listener.

This object applicable only to ProtocolProviderServiceJabberImpl class
(getConnection method). But it's not accessable from plugin module.

All the tries to import this class is not working coz there is no
packages that exports it.

The one way to import it from a plugin - to add a string

Export-Package: net.java.sip.communicator.impl.protocol.jabber

in
/jitsi/src/net/java/sip/communicator/impl/protocol/jabber/jabber.provider.manifest.mf

We believe that the way of making these changes directly in the
implementation of the protocol is absolutely incorrect, and the only
right one - to build this algorithm in a separate plugin, perhaps
attached to the product distribution.

In this way, we ask you to make these changes in the manifest file, so
that we can continue to improve the Jitsi project. Or at least we're
waiting of advice from you.

Isn't there a way to retrieve all active XMPP Connection objects directly from smack?

Emil

···

On 09.09.13, 17:08, Дмитрий Интеграл wrote:

Thank You.

Dmitry.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#3

Hi Emil. Thank you for your reply.

It would be great to limit such posts to once per mail.

Sorry. There was some e-mail delivery problem. I was forced to made
several attempts to post the message to the dev list...

FWIW, XEP-0198 is mostly meant for acknowledgements from the remote party.
The connection between the XMPP client and server is TCP, which gives you
everything you need to determine whether a specific message has been
received by the server.

According to http: // op-co.de/blog/posts/XEP-0198/
In some cases its not works(I mean tcp reliability). The quote "In the
good case, the connection is immediately closed by your network
provider, causing further messages to be stored on the server (my note
"In our way. the warning shows") In the bad case however, there is no
reply (because your provider employs paranoid admins), and the server
takes the usual TCP timeout (several minutes to hours) before taking
you offline."
So we're trying to serve these "bad cases".
Such behavior is often occurs on unstable networks, such as mobile
internet, 3G, etc.
You may clearly repeat this behavior by hard disabling network
interface on the server's side. Or by switching off the network router
in the middle of the connection between your client and server. (But
not your first router from the client - coz it'll cause local network
interface down and Jitsi should detect it).
In such cases - you'll loose all outgoing messages till timeout occurs.

Isn't there a way to retrieve all active XMPP Connection objects directly
from smack?

I could be wrong, but I didn't find the ways to retrieve all active
xmpp connections (it's important - from a separate plugin), without
obtaining a working instance(s) of the
ProtocolProviderServiceJabberImpl which has working xmpp connection
inside of it.

···

2013/9/10 Emil Ivov <emcho@jitsi.org>:

Hey Дмитрий,

It would be great to limit such posts to once per mail.

More inline.

On 09.09.13, 17:08, Дмитрий Интеграл wrote:

Hi All!

We're going to create a plugin for Jitsi to improve user experience of
Jabber protocol.

Our plugin will implement acknowledgment of all outgoing messages that
received by server.

We are faced to losing outgoing messages, in case of local network
malfunction. In these cases real network connection is not working, but
Jitsi keep it's connection online till keep-alive timeout occurs.

In this time window all outgoing messages are lost without any warning.

Only when timeout event occurs, and Jitsi obtains a connection lost
status - the warning shows and describes that this outgoing message can
not be delivered. But all messages before this last message was already
lost without any warning.

The plugin will partially implement XEP-198 (without session
resumption, but this XEP allows it) and improve behavior on servers
without XEP-198 support.

FWIW, XEP-0198 is mostly meant for acknowledgements from the remote party.
The connection between the XMPP client and server is TCP, which gives you
everything you need to determine whether a specific message has been
received by the server.

Due to the the fact that the lost messages can be life threatening, our
plugin will implement this algorithm (when activated):

-Plugin will buffer the all outgoing messages and then confirm an
acknowledgment from the server.

Same comment.

-If server support XEP-198 Stream Management, the plugin will ask an
acknowledgment of all outgoing messages from the server according to
XEP-198. After acknowledgment is recieved - this message will be deleted
from the buffer.

-If server does not support XEP-198, the plugin will make attempt to
ping server with XEP-199 ping request after the message was sent. On any
server answer (pong or error "not implemented") - the message will be
deleted from the buffer.

-Plugin will resends all the messages in the buffer (in case if it is
not clean) on all Jabber events of Reconnect (REGISTERED).

-Plugin will saves outgoing buffer on application close and restores in
state on starting.

We have already tested this algorithm by hardcoding it in Jitsi source
code of the test build. Everything is fine and works properly.

For now we want to create an separate plugin to community and publish it
in the right way, without modification of the Jitsi's core sources.

But faced a big problem:

Our plugin requires XMPPConnection object of all Jabber's service
providers to adding several Packet Listener.

This object applicable only to ProtocolProviderServiceJabberImpl class
(getConnection method). But it's not accessable from plugin module.

All the tries to import this class is not working coz there is no
packages that exports it.

The one way to import it from a plugin - to add a string

Export-Package: net.java.sip.communicator.impl.protocol.jabber

in

/jitsi/src/net/java/sip/communicator/impl/protocol/jabber/jabber.provider.manifest.mf

We believe that the way of making these changes directly in the
implementation of the protocol is absolutely incorrect, and the only
right one - to build this algorithm in a separate plugin, perhaps
attached to the product distribution.

In this way, we ask you to make these changes in the manifest file, so
that we can continue to improve the Jitsi project. Or at least we're
waiting of advice from you.

Isn't there a way to retrieve all active XMPP Connection objects directly
from smack?

Emil

Thank You.

Dmitry.

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
https://jitsi.org


#4

XEP-0198 was never intended to solve *all* possible network issues. It
was designed to solve the most serious and common network issues at
the time we wrote the spec (based on lots of feedback from some
engineers with quite a bit of mobile telephony experience).

If you have suggestions for further standardization in this space, I
encourage you to post to the standards@xmpp.org list:

http://mail.jabber.org/mailman/listinfo/standards

Peter

- --
Peter Saint-Andre
https://stpeter.im/

···

On 9/10/13 7:18 AM, ������� �������� wrote:

Hi Emil. Thank you for your reply.

It would be great to limit such posts to once per mail.

Sorry. There was some e-mail delivery problem. I was forced to
made several attempts to post the message to the dev list...

FWIW, XEP-0198 is mostly meant for acknowledgements from the
remote party. The connection between the XMPP client and server
is TCP, which gives you everything you need to determine whether
a specific message has been received by the server.

According to http: // op-co.de/blog/posts/XEP-0198/ In some cases
its not works(I mean tcp reliability). The quote "In the good case,
the connection is immediately closed by your network provider,
causing further messages to be stored on the server (my note "In
our way. the warning shows") In the bad case however, there is no
reply (because your provider employs paranoid admins), and the
server takes the usual TCP timeout (several minutes to hours)
before taking you offline." So we're trying to serve these "bad
cases".


#5

Hi Peter and Emil.
Thank you for your feedback.

XEP-0198 was never intended to solve *all* possible network issues. It
was designed to solve the most serious and common network issues at
the time we wrote the spec (based on lots of feedback from some
engineers with quite a bit of mobile telephony experience).

It seems there is a misunderstanding, probably due to problems with my
English coz it's not my native language.
I did not mean that the XEP-198 does not work. I did mean that TCP
connection tracking does not work properly in the described
situations.
All we want to do - implement the confirmation that the server
received a message from the client.
In XEP-198 way, if server supports it, otherwise - by XEP-199 Ping
after sending a message queue.

We using Jitsi more than a year. And I am grateful to the Emil and all
the team for a good project.
So we would like to contribute to the project by implementing a
separate plugin to support such acknowledgments, instead of source
patch or creating our own fork of the project.

All that we ask - is permit and approval from Emil, to add Jabber
Service Provider Implementation class functionality export, by
changing one string in manifest file of this package.
In that case it would be possible to interact directly with the XMPP
Connection and the Jabber Implemenation from the separate plugins.

Also, it can significantly speed up the project development, because
it'll provide the ability of creating XMPP extensions plugins to all
developers without
having to make changes to the source code of project's core.

Thank You.
Dmitry.

···

2013/9/11 Peter Saint-Andre <stpeter@stpeter.im>:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 9/10/13 7:18 AM, Дмитрий Интеграл wrote:

Hi Emil. Thank you for your reply.

It would be great to limit such posts to once per mail.

Sorry. There was some e-mail delivery problem. I was forced to
made several attempts to post the message to the dev list...

FWIW, XEP-0198 is mostly meant for acknowledgements from the
remote party. The connection between the XMPP client and server
is TCP, which gives you everything you need to determine whether
a specific message has been received by the server.

According to http: // op-co.de/blog/posts/XEP-0198/ In some cases
its not works(I mean tcp reliability). The quote "In the good case,
the connection is immediately closed by your network provider,
causing further messages to be stored on the server (my note "In
our way. the warning shows") In the bad case however, there is no
reply (because your provider employs paranoid admins), and the
server takes the usual TCP timeout (several minutes to hours)
before taking you offline." So we're trying to serve these "bad
cases".

XEP-0198 was never intended to solve *all* possible network issues. It
was designed to solve the most serious and common network issues at
the time we wrote the spec (based on lots of feedback from some
engineers with quite a bit of mobile telephony experience).

If you have suggestions for further standardization in this space, I
encourage you to post to the standards@xmpp.org list:

http://mail.jabber.org/mailman/listinfo/standards

Peter

- --
Peter Saint-Andre
https://stpeter.im/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSL8wSAAoJEOoGpJErxa2pdEoP/05fPacYZNUVP9tLIVudhqK8
PnI8GjSD3zJAn64vk7Facrm6u8HVLW9MyG++oeewRCONHLjdkJSnwR8i/YrIUzbS
/exSL3vFFdq4lyyJoWIuAzwZ9Df9vm32z2OjT2464rC98bhb2Wzvr0rjfNcrKJxp
G0E2hfOgQ24jc6RYPmq7lsWoAu7R2j6dbdqUVE+nwPhxMOGz6/MfgITIRAKFSi7N
I9yI4qOlKeWmavan5M6YBnG7+ewtsfUUgjCsIrLniQ5ijawaMfLATF8+RREuZ0/9
eJeqxAL5WBaRIq61pp4hAKg7qUxHWVVaIO+fzlFN3aXUqFJJAh8jO0x547R7IERp
ZqGeGmovSI37UmvEU0KV8dYg3itY98O+JONyggXY7D6L7FF5F3QOAl+iiWqP/mmb
9mRfOZuGeZHxq9gsz3SWKStosqBNN6hJn92T5lU3OtYqNZTLmDGSZf9KOsPbCwY4
xflKMeBKmrBzao4oUv6TmZeT00Mod1vzZ1cxndZqBqx+NvOQF2osx5LYtJ5hwTJX
VcYQEkH7jkSZxqzUpSQNh2y81+lLN7GtTVZQ+GhAJk8JO3xLqF4WCiNm0Z6qtEfK
ViAkonZO9UmzbdVQ4IoMzNzzNmoADFeat4RCQj5pn1U762lpiLDQoZTdwJX02zCZ
fgJqLQSvd8AsvV5Hc41h
=8/Ql
-----END PGP SIGNATURE-----