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 itso 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 upHmm. 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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ JDev mailing list FAQ: http://www.jabber.org/discussion-lists/jdev-faq Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [EMAIL PROTECTED] _______________________________________________
