Thanks for your input.
Thanks,
Tom
Robin Redeker wrote:
Hi Thomas!
I'll try to answer some questions, but I'm just a client developer, so I might
be wrong with some answers :)
On Tue, Mar 24, 2009 at 10:20:10PM -0400, Thomas Bolioli wrote:
All,
I am chair of a standards body developing a standard for allowing
devices to maintain their presence on the network while in a low power
state. Here is more detail on what we are looking to accomplish.
http://www.ecma-international.org/memento/TC32-TG21.htm
http://www.ecma-international.org/memento/TC32-TG21-M.htm
I am looking for some information on XMPP/Jabber and how it behaves in
certain circumstances. I have read through the RFCs and
http://xmpp.org/protocols/ but couldn't find the specific answer to my
question so I figured I would ask here. Most of the info I found
pertained to layers above layer 3/4 and it is the behavior of XMPP @
layer 3/4 that is most interesting for us right now.
So here goes:
Assuming for a moment this IM/presence scenario and keeping in mind that
IM can be replaced by any service/resource provided by an XMPP extension
and the use case should remain valid. I also understand XMPP to
implement a SIP like protocol.
Use case: Julie has her IM client up on client A. Client A is connected
to server B. Jim is on client Z connected to Server X.
In todays world, if client A goes to sleep/standby after a period of
inactivity, her connection to Server B is severed. If Jim sends her a
chat request or other message, that message is either terminated @
server B or held in lieu of Julie bringing the system back into a
working S0 state. Lets say for a hypothetical, that when Julie's system
went to sleep, it no longer dropped off of the network (ie; it
maintained it's IP, etc). Julie is waiting for directions for the
restaraunt where she will be meeting Joe. Julie is off reading a book
and is to leave once she gets word from Joe with the location. Yeah,
there will be better ways to get this info to Julie but lets assume cell
phones with SMS haven't been invented yet. :-) After 20 minutes her
system (client A) enters sleep and the IM client drops its connection to
the server (Q.1 Is there a connection to drop?). There will now be a
Yes, Client A communicates in XMPP via a TCP connection with Server B.
The problem is, that as soon as Client A drops the connection
the resource of Client A is broadcasted as unavailable and all messages
to Julie are either sent to other resources or stored on the Server B.
delay between when the information arrives on Server B and when Julie
gets it because Julie needs to wake up client A in order for the IM
client to check in and retrieve the cache of backlogged messages in the
queue on server B. Q2. Does XMPP have a facility for Server B to send a
message to client A when all are on public IPs?
There is no communication channel between Server B and Client A other
than the TCP connection that is initiated by Client A.
I currently don't know about any servers or extension protocols that 'notify'
the Client A when it is offline.
Q3. When client A is
behind a NAT (ie; does XMPPs version of SIP have nat traversal)?
What do you mean btw. with 'SIP like protocol' above and 'XMPPs vrsion of SIP'
here?
(I'm not too familiar with SIP).
All client2server connections are initated and maintained by the client
software. The server has no way of contacting a client when it is offline.
It's not like SIP that clients are always running and can be contacted directly
when they are not connected.
The only thing that afaik has to do with SIP in XMPP is the extension protocol
for audio/video/file-transfer between two clients on the network. That
protocol (Jingle) uses ICE to create a communication channel between Client A
and Client Z. But no such protocol exists for Client A and Server B - at least
as far as I know.
So if
the message is truly pushed to client A from Server B, client A simply
needs to wake up to gather/respond the incoming message and the PC
sitting next to the reading Julie will alert her within a short timespan
that Joe has sent his message to her. Since client A never left the
network, IP routing is still possible and the TCP SYN is routable to the
waiting client (assume a route was available to redirect from the router
to the PC in the case of a NAT scenario).
Q5. The client and server communicate via SOAP or a SOAP like XML based
transactional protocol over TCP, correct?
Not at all. The protocol on the wire is a pseudo-XML "streaming" protocol,
which uses the nesting of XML tags for framing. Messages, presence information
and
other queries are currently pushed from client to server and from server to
client without any acknowledgements.
Greetings,
Robin
