[jdev] Communicate between two client instances of the same ID

[Peter Saint-Andre]

JLIST wrote:
>> And how do you define "guaranteed delivery"? At least once? At most
>> once? Delivery with receipt? Delivery with receipt per-hop? Delivery
>> with cryptographically signed receipts?
> 
> I think delivered and delivered once would be good enough for me.
> If not delivered for any reason, I'd like to be notified about it
> so that I'll resend it. 

Message receipts (XEP-0184) probably give you what you want, then.

> But the ideal solution would be like yahoo
> or msn messenger which store undelivered messages and retries (if
> the remote user is not online or not reachable.)

We store undelivered messages if the user is offline, and have since 
1999. If something less expected happens (TCP outage or whatever), the 
message can be lost. See XEP-0198 for relief there (but recognize that 
it is unfinished  and unimplemented).

>>> Requests will be a few KBytes, replies a few KBytes to a few hundred
>>> KBytes typically. For larger replies, I suppose I can chunk them up
> 
>> Hmm. XMPP is not optimized for sending around 100k+ messages.
> 
> Would 64KB chunks a reasonable thing to do?

Just as one data point, the jabber.org IM service (of which I'm an 
admin) outright rejects all stanzas larger than 64k. If you send a large 
number of 63k chunks, it is very likely you will run into rate limits 
(a.k.a. "karma"). To repeat, XMPP is *not* optimized for sending lots of 
64k data chunks -- it's basically optimized for sending lots of chunks 
1k or smaller.

/psa
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6751 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.jabber.org/jdev/attachments/20080902/3c3255e0/attachment-0002.bin>