Opened 6 years ago

Last modified 5 years ago

#15320 new defect

reliably send/receive XMPP messages

Reported by: calestyo Owned by: deryni
Milestone: Component: XMPP
Version: 2.10.6 Keywords:
Cc:

Description

Hi.

A long standing problem with XMPP clients (and to some extent even servers) is that messages are not transferred reliably. AFAICS pidgin was always affected by this.

One easily notices this problem when using an unstable internet connection like when you're on a high speed train and use UMTS, which breaks down every 2nd tunnel or so.

Messages you sent or you should have received by others get lost.... and even worse, you don't get any notice about anything was lost.

Actually it turns out that UDP based protocols like ICQ work in practise much more stable in these cases as they have much less protocol overhead (which increases the chance that something gets broken).

To my understanding, TCP, which XMPP use should offer everything that is needed to reliably receive and send messages; the client (in this case pidgin) would just need to use that.

So the general request: Use all functionality (likely that of TCP) to reliably send/receive XMPP messages.

This includes to re-send or -request messages till the transfer succeeded or till a XMPP error state occured. It also includes that the user is warned about some lost messages, if finally (e.g. after some configurable timeout that may be even weeks) the client has to give up.

Some thoughts: 1) Skype (even though it is evil) has for example the nice technique to indicate when the other end has received a message. I doubt this was possible by the means of TCP alone, but maybe XMPP offers something for this at the higher level.

2) At lest TCP should be enough to tell whether something send/or received to/from the client failed or was out of order (e.g. the server sent messages in between, that haven't arrived however).

3) Of course, the client should try to re-send/-receive messages till a higher (XMPP) level error tells to give up or till a user configurable timeout occurs. Of course a broken TCP connection is NOT a reason to give up.

4) On the client's side it's of course necessary to temporarily store all sent messages that couldn't be correctly delivered to the server. Later on (e.g. in configurable intervals, or on events like reconnects) the client should try to resend them (and remove them from the list, once that succeeded).

5) For receiving it depends on whether the server correctly determines whether a message was sent to the client successfully or not,.. and in the later case retains the message.

6) In both cases one has to take care on time stamps. Obviously when I send a message which can only be delivered (to the server!) a week after,... one still wants to have the time from when it one clicked "send".

7) In both cases one has to take care on the history logs and the IM window. The re-sending/-receving means that messages could arrive out of order. One must think about a proper way of handling this:

  • either inserting the messages at the proper place (and denoting somewhere, that something new has arrived above)..
  • or appending it at the end (also with some special sign denoting that this is out of order).

8) Likely there are other things one needs to consider.

Cheers, Chris.

Change History (1)

comment:1 Changed 5 years ago by calestyo

Anything new here?

I mean this is one of THE core functionalities of IM, and especially those protocols that can be reliable (unlike e.g. ICQ, which is based on UDP, IIRC)...

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!