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

[JLIST]

Thanks Pedro and Kevin for the replies.

Yes, I meant <iq />, not <ip /> :)

I come from the TCP/IP world (as you can tell :) and I'm trying
to understand how streams work in XMPP. Let's say I send out
two <message /> messages. If they are delivered, are they
guaranteed to be delivered in the same order they are sent?

Regarding guaranteed delivery, if the transport protocol
is TCP, I suppose there's no reason a delivery fails unless
TCP connection is closed and the TCP packet isn't sent out,
in which case I suppose the client will be notified by
the socket layer. So, if no error happens at the socket
layer, there's no reason the packet will be dropped or fail
to deliver at XMPP layer, right? In other words, I expect
XMPP message delivery works more like TCP rather than UDP,
which may drop packets when network condition is bad.

jlist

Tuesday, September 2, 2008, 9:30:17 AM, you wrote:

> Hi,

> On Sep 2, 2008, at 5:12 PM, JLIST wrote:

>> Thanks Pedro! Although <message /> doesn't get a reply,
>> I suppose its delivery is still guaranteed by the transport?

> No, unless you use http://www.xmpp.org/extensions/xep-0079.html and
> AFAIK no server supports that. So if you need reliability, I would use
> IQ for now.

>> I'm thinking, <message /> sounds more efficient than <ip />

> <iq />, not <ip />.

> <ip /> gives me scary thoughts :)

>> when relatively large amount of data needs to be transferred
>> because it doesn't require an XMPP level response.

> it wont be a huge overhead because the IQ response is tiny.

> And IQ is 2 chars, MESSAGE is 7 :)

> Best regards,

>>
>>
>>>> A follow up question is, what would be the right element
>>>> of the protocol to use to send and receive custom data?
>>>> It'll be very helpful to me if someone can point me to
>>>> a link or some names that I can search for.
>>
>>> You can use two:
>>
>>> <message /> or <iq />.
>>
>>> the main difference is that <iq /> is a request/response dialog: you
>>> sen a <iq type="set"> or a <iq type="get"> and get back a <iq
>> type="result">> or a <iq type="error">. The id attribute of the
>>> response matches the id of the request.
>>
>>> The <message /> is more of a send and forget about it style of
>>> communication.