[Pidgin] #15320: reliably send/receive XMPP messages

[Pidgin]

#15320: reliably send/receive XMPP messages
----------------------+--------------------
 Reporter:  calestyo  |      Owner:  deryni
     Type:  defect    |     Status:  new
Milestone:            |  Component:  XMPP
  Version:  2.10.6    |   Keywords:
----------------------+--------------------
 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.

-- 
Ticket URL: <https://developer.pidgin.im/ticket/15320>
Pidgin <http://pidgin.im>
Pidgin