Subject: [SWMP] What is the relationship of SWMP to SIP and/or XMPP?

From: [email-masked]
Date: Wed, 13 Jun 2007 18:23:07 -0400

[Sorry, I have not yet read the paper.]

Presumably, SWMP needs to be a low latency state sharing mechanism with 
some form of virtual world specific pub-sub model.

Although SIP (really SIMPLE) and XMPP were designed for "buddy list" like 
awareness.  They do define a low latency state sharing mechanism with a 
"buddy list"-specific pub-sub model.  At first blush it would seem 
sensible to ask whether the transport layers for SIP and/or XMPP are 
serviceable for SWMP and, if so, focus attention on the virtual 
world-specific pub-sub model.

John F. Patterson
IBM Distinguished Engineer
Collaborative User Experience (CUE) Research Group
[email-masked]

_______________________________________________
SWMP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/swmp

---

From: "Jay C. Weber" <[email-masked]>
Date: Wed, 13 Jun 2007 20:17:50 -0700

[email-masked] wrote:

Although SIP (really
SIMPLE) and XMPP
were designed for "buddy list" like awareness.  They do
define a low latency state sharing mechanism with a "buddy
list"-specific
pub-sub model.  At first blush it would seem sensible to ask whether
the transport layers for SIP and/or XMPP are serviceable for SWMP and,
if so, focus attention on the virtual world-specific pub-sub model.

Hi John, a very good question.  I argued with myself over using XMPP
for some time.  In the end, like most multiuser-3D implementors I
believe, I decided that bandwidth efficiency is just too important
(much moreso than for chat) to not have a packed binary protocol,
especially over the fairly inefficient ascii encoding of XML as
required by XMPP.  A similar situation to why, to my knowledge, nobody
uses XML encodings to stream audio or video.

That is, I reluctantly turned away from XMPP as an encoding for
position-data streams.  As I understand it, XMPP is an application
protocol so it doesn't specify transport layers to adopt, except in the
sense that people usually carry XMPP over TCP, and SWMP does use TCP as
transport (as well as UDP).

I know SIP/SIMPLE less well, but I do understand that SIP is an
application protocol and likewise built on top of the standard
transports.  Interesting idea though to use SIP to establish the
sessions, or similarly, for SWMP to subsume SIP messaging.  I'll
definitely look into that.

jay

--

Jay C. Weber

CTO, Media Machines

---

From: "Tony Parisi" <[email-masked]>
Date: Wed, 13 Jun 2007 22:01:08 -0700

Just to be clear:

We are planning to enable XMPP integration for the chat and presence, just
not 3D state sharing because of the particularly demanding requirements.

Tony

  _____  

From: Jay C. Weber [mailto:[email-masked]] 
Sent: Wednesday, June 13, 2007 8:18 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [SWMP] What is the relationship of SWMP to SIP and/or XMPP?

Although SIP (really SIMPLE) and XMPP were designed for "buddy list" like
awareness.  They do define a low latency state sharing mechanism with a
"buddy list"-specific pub-sub model.  At first blush it would seem sensible
to ask whether the transport layers for SIP and/or XMPP are serviceable for
SWMP and, if so, focus attention on the virtual world-specific pub-sub
model. 

Hi John, a very good question.  I argued with myself over using XMPP for
some time.  In the end, like most multiuser-3D implementors I believe, I
decided that bandwidth efficiency is just too important (much moreso than
for chat) to not have a packed binary protocol, especially over the fairly
inefficient ascii encoding of XML as required by XMPP.  A similar situation
to why, to my knowledge, nobody uses XML encodings to stream audio or video.

That is, I reluctantly turned away from XMPP as an encoding for
position-data streams.  As I understand it, XMPP is an application protocol
so it doesn't specify transport layers to adopt, except in the sense that
people usually carry XMPP over TCP, and SWMP does use TCP as transport (as
well as UDP).

I know SIP/SIMPLE less well, but I do understand that SIP is an application
protocol and likewise built on top of the standard transports.  Interesting
idea though to use SIP to establish the sessions, or similarly, for SWMP to
subsume SIP messaging.  I'll definitely look into that.

jay
--
Jay C. Weber
CTO, Media Machines

---

From: "Tony Parisi" <[email-masked]>
Date: Wed, 13 Jun 2007 22:11:01 -0700

Just to be extra clear: when I say "we are planning to enable XMPP" I am
talking about within our own applications. They will use XMPP for chat and
presence and SWMP for 3D state. Sorry for any confusion.

Tony

  _____  

From: Tony Parisi [mailto:[email-masked]] 
Sent: Wednesday, June 13, 2007 10:01 PM
To: 'Jay C. Weber'; [email-masked]
Cc: [email-masked]
Subject: RE: [SWMP] What is the relationship of SWMP to SIP and/or XMPP?

Just to be clear:

Tony

  _____  

jay
--
Jay C. Weber
CTO, Media Machines

---

From: "Sven-Erik Tiberg" <[email-masked]>
Date: Thu, 14 Jun 2007 11:00:19 +0200

Hi.
 
I'm Sven-Erik Tiberg at Lulea Univ. of Technology / Sweden and one of my
interest are Distributed Real-Time simulations like low-cost client
-server driversimulators using X3D Human Mashine Interface with haptic
and server-side simulation engines like Mathworks/simulab-models,
carsim.com, racer.nl or Aspentech.com for process simulations. 
 
Collected some info at http://tellus.arb.ltu.se/moodle WBSP_public.
 
Current "challange" are communication of states between HMI-client and
simulationengine-server. Have been looking into DIS and a custom made
raw-data transfer over UDP using python.twisted on client side. 
DIS seems to have rerached it's end of developent and are not so easy to
get info about.
UDP raw-data are a custom made ( me ) protocol that needs some work on
the client side and are non std.
 
Learned about SWAMP from jay at mediamachines and the info about it
covers my livingroom desk and more places at home. And my mind are not
compleatly with my family all the time.
 
Some Q. before I compleatly dissapear behind my papars and laptop:
In a driver simulator there are some looptimes for updates, the
outerloop HMI <> car model use to be <= 50 mSec. 
The outerloop will be used for transport of states beween client and
server, any limitations in SWAMP on this?
 
/ Thank for letting me join your e-discussions.
 
Sven-Erik Tiberg 
IT - dept. 
Lulea Univ. of Technology 
Sweden

---

From: Alan Hudson <[email-masked]>
Date: Thu, 14 Jun 2007 07:50:44 -0700

> not 3D state sharing because of the particularly demanding requirements.

I've had a fair bit of luck pushing entity locations over XMPP.  I have 
also prototyped using XML binary to deliver the data(using XMPP 
attachments).  I liked having the open source servers already available 
and the services available to them(replication, logging, security)...

That said, I suspect you can hand roll a direct binary protocol that 
will be faster.  Though I think the XML binary work will be comparable.

Not sure how much extensibility is needed in this protocol.  For me the 
ability to add new parts to the protocol over time has been a big help. 
  Parsing XML makes the client very resilient to changes in the 
format(at least additions).  I also like XML's model of allowing 
optional data without enlarging the data packet.  A study I did of DIS 
showed it used about 20% of its packet size on extensions mechanisms.

I like the work NPS did on Bamboo.  The idea was to have a multi-user 
simulation that never was down for maintenance.  You had to be able to 
extend the system in pieces.  The clients would need to know how to 
gracefully ignore new data items.  XML has a nice mechanism for this.

The other reason we use XMPP is to lower the barrier of entry to the 
system.  Lots of people know how to program for XML.  Any library we 
develop to directly talk to this protocol will be less understood and 
less widely available then XML libraries.

There's the sell for XMPP from my side.  Its been convinient to use at a 
cost of some performance.  I like some of the features it gives us.  But 
perhaps those features could just be designed into a similar system.
-- 
Alan Hudson

President Yumetech, Inc.                               www.yumetech.com
President Web3D Consortium                             www.web3d.org
206 340 8900