Opened 6 years ago

Last modified 13 months ago

#15388 new enhancement

XMPP feature "XEP-0079" to handle lost messages

Reported by: kolAflash Owned by: deryni
Milestone: Component: XMPP
Version: 2.10.6 Keywords: XMPP lost message XEP-0079
Cc: devurandom, marsjaninzmarsa, kaptoxic

Description

Hi, specially when my notebook is connected via wireless network e.g. umts it can happen that my network connection gets lost without a signoff from the XMPP server.

In that case it can happen that somebody sends me a message an I'll never get it, because usual XMPP doesn't includes that the clients acknowledges message receptions. So until my clients reconnects to the server or the connection to the server times out all messages will be lost.

To handle this, there is the "XEP-0079" extension for XMPP. http://xmpp.org/extensions/xep-0079.html

Can you please implement this in Pidgin/libpurple? Currently the Tigase XMPP server and maybe some more servers provide this feature. http://www.tigase.org/content/xep-0079-advanced-message-processing-support-tigase https://projects.tigase.org/projects/tigase-server/files

Tigase also has an own server running their Tigase server software. http://tigase.im

Please do not consider this as just an enhancement. In some way it's a bug in the XMPP protocol and it leads to very unforeseeable behavior.

Additionally it would be nice if Pidgin tells me if my server currently supports the feature.

Thanks! kolAflash

Change History (10)

comment:1 Changed 6 years ago by Robby

  • Milestone 3.0.0 deleted

Please do not arbitrarily set milestones.

comment:2 Changed 6 years ago by tremby

I've noticed that every time I change from wifi to wired or back incoming messages are lost and my messages are not sent, until I manually reconnect the XMPP account. If implementing the above would clear this up, that'd be great.

comment:3 Changed 6 years ago by notphilipfry

simultaneously consider

Stream Management, XEP-0198, XEP-0184 Delivery Receipts XEP-0280 Message Carbons xep-0146 Remote Controlling Clients

..

Last edited 6 years ago by notphilipfry (previous) (diff)

comment:4 Changed 5 years ago by kolAflash

Currently using the Pidgin plugin mentioned in this ticket for XEP-0184 which is also supported by http://www.xabber.com/ for example.

https://developer.pidgin.im/ticket/6940

Nevertheless a complete message-management by XEP-0079 and copies to all other clients by XEP-0280 would be really cool too!!!

http://xmpp.org/extensions/xep-0079.html http://xmpp.org/extensions/xep-0280.html

comment:5 Changed 5 years ago by devurandom

XEP-0198 (stream management) is a simpler version of this, is that correct? It is dealt with in bug #14252

comment:6 Changed 5 years ago by kolAflash

I'm not sure but I think it's like this. There is some difference and both (XEP-0198 and XEP-0079) extensions should be implemented.

XEP-0079 Advanced Message Processing The receiving client tells the sending client if it received a message.

Advantage: Only the clients need to implement XEP-0079. It's not necessary to have a server implementing this.

Disadvantage: If the receiving client doesn't supports XEP-0079 the sending client won't know if a message didn't arrived of the receiving client just doesn't supports XEP-0079. Because of this, it's also not easily possible to auto-resend a message if it didn't arrived. It also doesn't makes sense for the sending client to find out once, if the receiving client supports XEP-0079. Because the receiving clients software could change to some not supporting XEP-0079 (e.g. closing Pidgin and starting another program) at any time without the sending client recognizing.

XEP-0198 Stream Management This is always being used between two direct communication partners. This can be:

sending client <=> server of the sending client

server of the sending client <=> server of the receiving client

server of the receiving client <=> receiving client

Advantage: When a connection between a client and a server or two servers becomes established, they can exchange information about if they both support XEP-0198. Afterwards they can automatically exchange information about messages being received. They'll also recognize, if the software on the other side changes (e.g. closing Pidgin and starting another program) so they'll always know if a message got lost or the other side just doesn't supports XEP-0198.

Disadvantage: All clients and servers have to support XEP-0198 to make it fully work.

You see XEP-0198 is maybe the better way to do it, but until every server and client support XEP-0198 (which will probably never happen) XEP-0079 is the more pragmatic way.

comment:7 Changed 4 years ago by hobarrera

Most servers support XEP-0198, and it handles what this issue describes properly. In case of disconnects, messages will make it thourgh (in both directions) upon reconection.

XEP-0079 requires that all clients support is, and the ones that do are a minority. Some most likely never will. It also means it's not up to you if your message is lost or not - XEP-0198 leaves you in control (since you can pick which server you use).

You don't need the other party's client to support XEP-0198 if you're the one having disconnections, just your server+client.

comment:8 Changed 4 years ago by tejasgslab

We have developed the plugin to ensure that no messages are lost (in the context of Openfire). Using Openfire, in the presence of a weak network, messages/packets are lost. Hence, to ensure deliveries (at-least-once) and no message/packet losses we have developed the plugin. The plugin ensures 'Stanza Acknowledgements' (the ability to know if messages have been received by one's peers) with no losses (at-least-once deliveries).

For more information, please see- https://www.atklique.com/bridge/blog/?q=node/5

For more information (and integration of the plugin with Openfire), please drop an email to support@… with you requirements.

comment:9 in reply to: ↑ description Changed 4 years ago by inamdartejas

Using Openfire, in the presence of a weak network (or when user switches/changes the network), messages/packets are lost.

'Stop Message Loss' plugin may serve your need well. Please see- https://www.atklique.com/bridge/blog/?q=node/5

To download the plugin, click the tab 'Stop Message Loss' (scroll to the bottom).

The plugin ensures that no messages are lost (in the context of Openfire). It implements server acknowledgement for each message received by the server. The plugin ensures deliveries (at-least-once).

Replying to kolAflash:

Hi, specially when my notebook is connected via wireless network e.g. umts it can happen that my network connection gets lost without a signoff from the XMPP server.

In that case it can happen that somebody sends me a message an I'll never get it, because usual XMPP doesn't includes that the clients acknowledges message receptions. So until my clients reconnects to the server or the connection to the server times out all messages will be lost.

To handle this, there is the "XEP-0079" extension for XMPP. http://xmpp.org/extensions/xep-0079.html

Can you please implement this in Pidgin/libpurple? Currently the Tigase XMPP server and maybe some more servers provide this feature. http://www.tigase.org/content/xep-0079-advanced-message-processing-support-tigase https://projects.tigase.org/projects/tigase-server/files

Tigase also has an own server running their Tigase server software. http://tigase.im

Please do not consider this as just an enhancement. In some way it's a bug in the XMPP protocol and it leads to very unforeseeable behavior.

Additionally it would be nice if Pidgin tells me if my server currently supports the feature.

Thanks! kolAflash

comment:10 Changed 13 months ago by kaptoxic

What is the status on this one? Are "XEP-0079" or "XEP-0198" implemented in pidgin? (I think the link to the plugin is dead.)

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!