[standards-jig] Pub/Sub for JNG?

Dave dave at dave.tj
Wed May 1 21:36:36 UTC 2002

I have no particular comment about #3 (since I haven't thought of it
seriously, so my opinion really doesn't count).  However, #1 and #2
(as well as our standard connection method) aren't mutually exclusive.
I think we should allow entities to negotiate each connection in
order to optimize network utilization.  In fact, we may be able to
pull off a further generalization, having TCP/UDP be one property,
uncompressed/gzipped/bzipped to be another property, etc. - so entities
can indicate their desired value for each property.  (Anybody who uses
the bzip format for anything other than _huge_ data transfers is probably
crazy, but that's not a good enough reason not to allow Jabber entities
to use it if they wish to, and their peers don't object.)  For large
transfers between "close" (in network terms) Jabber servers, UDP may
actually be better even for s2s (but don't quote me on that - I'm just
speculating); regardless, my opinion is that the Jabber protocol should
give entities the right to decide how to communicate with other entities.
Flexibility is the name of the game.

 - Dave

Iain Shigeoka wrote:
> Wow, this thread sure has taken off.  :)  
> 1) compressed streams
> I'm mixed on this.  As mentioned earlier, it was shown
> that you can compress Jabber streams to lower bandwidth.
> IM servers are typically network bound so the computation
> overhead of compression should not slow the overall
> performance of the server.
> I believe the last time this came up, it was eventually dropped
> because the benefits just didn't justify the added complexity.
> Ideally, I suppose we should try to make this a negotiable
> transport feature.  It seems to come up enough that no
> matter what the group decides, there will be enough people
> in the other camp that will want to do the opposite.
> I believe we can design a transport system that can accomodate
> this.
> 2) UDP
> Technically, I think UDP is good idea.  Especially in situations
> where we could exploit multicast.
> I imagine that the main reason people avoid it though is difficulty
> in making a good implementation based on UDP, and firewall
> issues.  The latter would seem to me to be the largest issue.
> For all its technical advantages, I think UDP is simply a non-starter
> for us if we want to get inside enterprises.
> 3) transport switching
> Switching transport layers would be really nice to have.  I'm
> not sure how you would do it in practice but would be interested
> in seeing a proposal for details in this direction.
> Perhaps simply standardizing multiple transports of the Jabber
> protocols is the way to go.  Then an HTTP Jabber client would
> just have to know where an HTTP Jabber server was and use
> it.  That way, servers/clients won't have to support some 
> bootstrap protocol to negotiate transports.
> The down side being multiple transports effectively fragments
> the Jabber network into transport "islands".
> -iain
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Health - your guide to health and wellness
> http://health.yahoo.com
> _______________________________________________
> Standards-JIG mailing list
> Standards-JIG at jabber.org
> http://mailman.jabber.org/listinfo/standards-jig

More information about the Standards mailing list