Re: Bytestreams fallback mechanism

Le vendredi 28 décembre 2007 à 09:39 -0700, Peter Saint-Andre a écrit :
> > Tubes are currently implemented in Gabble (XMPP) and Salut (XMPP link
> > local). See [2] if you are interested about the XMPP protocol.
> > Stream tubes use stream initiation 
> 
> By which I assume you mean XEP-0095.
> 

Exactly.

> > to establish their connections. For
> > now, only IBB is implemented in Gabble which is not very efficient. So
> > we'd like to add real p2p connections as OOB 
> 
> By OOB we usually mean XEP-0066. I don't think that gives you a real p2p 
> connection, though -- it's just a way to share a URI.

By OOB I usually mean "a direct p2p connection".
I started an implementation of this using XEP-0066 and URI of this form:
"x-tcp://<my-ip>:<port>"
That's probably a kind of abuse of XEP-0066 but that can easily do the
job.

Of course, that will only work if the joiner can reach initiator's IP
(and so are probably on the same network) but that's not a too bad
assumption for most of the OLPC use cases.

> It seems to me that you really want XEP-0065, where the initiator acts 
> as a streamhost.

Re: Bytestreams fallback mechanism

Ar 28/12/2007 am 09:39, ysgrifennodd Peter Saint-Andre:
> I'm working on the Jingle ICE-UDP spec at the moment, and I think that 
> would give you what you need (at least I think it would -- your 
> requirements are not fully clear to me).

For most cases, we want to open a TCP-like connection. ICE-UDP would be nice,
but we'd need to layer retransmission/reordering on top of it.

> Well of course you can define your own protocol, but I would bet that 
> other people are interested in similar functionality, so it might be 
> more productive to see if you can use Jingle and if not what gaps we 
> need to fill in Jingle so that it would work for you.
> 
> For example, perhaps we need a way to more seamlessly include things 
> like SOCKS5 Bytestreams and IBB as options in a Jingle negotiation (or 
> include Jingle as an option in a stream initiation negotiation, e.g. for 
> file transfer). We talked about that back in August or September, but I 
> have not yet documented how that might work.

Indeed, I can see a case both for including SOCKS5 and IBB in Jingle and
including Jingle UDP in SI. I would lean towards making sure Jingle has decent
negotiation/fallback semantics and a good set of transport options rather than
trying to shoehorn Jingle into SI.

--

-- 
Dafydd

Re: Bytestreams fallback mechanism

Dafydd Harries wrote:
> Ar 28/12/2007 am 09:39, ysgrifennodd Peter Saint-Andre:
>> I'm working on the Jingle ICE-UDP spec at the moment, and I think that 
>> would give you what you need (at least I think it would -- your 
>> requirements are not fully clear to me).
> 
> For most cases, we want to open a TCP-like connection. ICE-UDP would be nice,
> but we'd need to layer retransmission/reordering on top of it.

We're waiting on ICE-TCP to be finished at the IETF before we document 
how that would work with Jingle. The latest version is here:

http://tools.ietf.org/html/draft-ietf-mmusic-ice-tcp-05

>> Well of course you can define your own protocol, but I would bet that 
>> other people are interested in similar functionality, so it might be 
>> more productive to see if you can use Jingle and if not what gaps we 
>> need to fill in Jingle so that it would work for you.
>>
>> For example, perhaps we need a way to more seamlessly include things 
>> like SOCKS5 Bytestreams and IBB as options in a Jingle negotiation (or 
>> include Jingle as an option in a stream initiation negotiation, e.g. for 
>> file transfer). We talked about that back in August or September, but I 
>> have not yet documented how that might work.
> 
> Indeed, I can see a case both for including SOCKS5 and IBB in Jingle and
> including Jingle UDP in SI. I would lean towards making sure Jingle has decent
> negotiation/fallback semantics and a good set of transport options rather than
> trying to shoehorn Jingle into SI.

Re: Bytestreams fallback mechanism

On Jan 2, 2008 8:58 AM, Peter Saint-Andre <stpeter <at> stpeter.im> wrote:
> Dafydd Harries wrote:
> > Ar 28/12/2007 am 09:39, ysgrifennodd Peter Saint-Andre:
> >> I'm working on the Jingle ICE-UDP spec at the moment, and I think that
> >> would give you what you need (at least I think it would -- your
> >> requirements are not fully clear to me).
> >
> > For most cases, we want to open a TCP-like connection. ICE-UDP would be nice,
> > but we'd need to layer retransmission/reordering on top of it.

There does need to be a standardized reliable stream layer on top of
UDP type Jingle connections.

In Google Talk we have one which you can see in the libjingle source
code, called PseudoTcp.

Before standardizing, as a point of comparison, some of the dedicated
file sharing clients also have "reliable stream on top of UDP"
implementations. The topic is complicated; I propose the design of
choice optimize for reliability, throughput, and simplicity, in that
order.

Re: Bytestreams fallback mechanism

Scott Ludwig wrote:
> On Jan 2, 2008 8:58 AM, Peter Saint-Andre <stpeter <at> stpeter.im> wrote:
>> Dafydd Harries wrote:
>>> Ar 28/12/2007 am 09:39, ysgrifennodd Peter Saint-Andre:
>>>> I'm working on the Jingle ICE-UDP spec at the moment, and I think that
>>>> would give you what you need (at least I think it would -- your
>>>> requirements are not fully clear to me).
>>> For most cases, we want to open a TCP-like connection. ICE-UDP would be nice,
>>> but we'd need to layer retransmission/reordering on top of it.
> 
> There does need to be a standardized reliable stream layer on top of
> UDP type Jingle connections.
> 
> In Google Talk we have one which you can see in the libjingle source
> code, called PseudoTcp.
> 
> Before standardizing, as a point of comparison, some of the dedicated
> file sharing clients also have "reliable stream on top of UDP"
> implementations. The topic is complicated; I propose the design of
> choice optimize for reliability, throughput, and simplicity, in that
> order.

It seems that some file sharing applications use reliable UDP (RFC 1151) 
but it also seems that some similar technologies exist that have not 
been standardized....

Peter

--

-- 
Peter Saint-Andre

Re: Chaminda sent you a friend request on Yaari...

Re: Chaminda sent you a friend request on Yaari...

The person who sent that message is now subject to moderation.

On Thu, Jan 03, 2008 at 06:20:52PM +0530, krish wrote:
> wtf, on jdev?
> 
> This isn't a list for finding soulmates. [:X]
> 
> On Jan 3, 2008 3:57 PM, Chaminda <chami.groups <at> gmail.com> wrote:
> 
> >  Chaminda Amarasinghe wants you to join Yaari!

XSF membership application period Q1/2008

The XMPP Standards Foundation (XSF) is currently holding its quarterly 
membership application period:

http://wiki.jabber.org/index.php/Membership_Applications_January_2008

Applications are encouraged from developers and others who are actively 
involved in the Jabber/XMPP community. To apply, create a page about 
yourself on the wiki.

If you don't have a wiki account, send your name and email address to 
one of the Sysops:
http://wiki.jabber.org/index.php/Sysops

The application period ends on 20th January 23:59h UTC, so apply today!

Thanks.

Alex

Collaboration on BOSH servlet?

Hi all,

I've just tuned into the Jabber/XMPP/BOSH stuff.  I'm the main developer of the Jetty webserver and
a contributor to the Cometd/Bayeux project at Dojo.

I've recently been working on using the async features of Jetty to scale Cometd/Bayeux to
20,000 simultaneous users on one server: http://cometdaily.com/2008/01/07/20000-reasons-that-comet-scales/

I think that BOSH and XMPP over BOSH are essentially the same technique as the long polling used
by Bayeux/cometd, so it should be possible to come up with a java servlet that scales to similar levels
for BOSH/XMPP

So a couple of questions (some/most being a bit newbie in nature):

While I understand that much/most/many XMPP applications talk to dedicated servers, what is the
interest in having XMPP/BOSH terminating in a standard java web container?

What is the state of the art with regards to XMPP/BOSH servlets. Googling reveals a somewhat
confused and perhaps dated picture?

The BOSH spec looks pretty straight forward and very similar to what we have for Bayeux/cometd
I should be able to implement that in a week or so.    But will that be sufficient for XMPP
clients and servers to use it or will I need to write some XMPP adaption/integration stuff
as well?

Any interest out there for a BOSH transport for cometd/bayeux?

Is this the right forum/community to be asking these questions?

If there are any similar efforts underway, then I'm happy to collaborate with them.
But then I'm also happy to create a totally new BOSH implementation and would be keen to
meet anybody interested in Collaboration.

cheers

Re: Collaboration on BOSH servlet?

On Wednesday 09 January 2008 08:08:05 Greg Wilkins wrote:
> Hi all,
>
> I've just tuned into the Jabber/XMPP/BOSH stuff.  I'm the main developer of
> the Jetty webserver and a contributor to the Cometd/Bayeux project at Dojo.
>
> I've recently been working on using the async features of Jetty to scale
> Cometd/Bayeux to 20,000 simultaneous users on one server:
> http://cometdaily.com/2008/01/07/20000-reasons-that-comet-scales/
>
> I think that BOSH and XMPP over BOSH are essentially the same technique as
> the long polling used by Bayeux/cometd, so it should be possible to come up
> with a java servlet that scales to similar levels for BOSH/XMPP
>
> So a couple of questions (some/most being a bit newbie in nature):
>
> While I understand that much/most/many XMPP applications talk to dedicated
> servers, what is the interest in having XMPP/BOSH terminating in a standard
> java web container?
Sorry, I can not understand that question. Not a java developer, see...

> What is the state of the art with regards to XMPP/BOSH servlets. Googling
> reveals a somewhat confused and perhaps dated picture?
There are severeal implementations of BOSH are available. Punjab, http-bind 
for ejabberd, something in openfire (btw - in java), may be some more. Most 
of them are [nearly ]complete. openfire and ejabberd are the jabber servers 
with http support. punjab is a dedicated software that serves http port and 
connects to jabber server. AFAIK - there are no _http_ servers that support 
bosh natively, so far I've seen only 'proxy connection' configurations that 
forward requests to nearest bosh server.

> The BOSH spec looks pretty straight forward and very similar to what we
> have for Bayeux/cometd I should be able to implement that in a week or so. 
>   But will that be sufficient for XMPP clients and servers to use it or
> will I need to write some XMPP adaption/integration stuff as well?
Well, that depends on what you are calling 'XMPP integration'.
Yes, I think you'll need somewhat light-to-medium integration. Before it was 
the single spec (http-bind), but later it was split in two to clearly divide 
transport stuff from protocol stuff. Still, as I understand - stream 
initiation/termination and may be stream errors passing also should be 
handled separately.
Though, if you just implement what is required in XEP-0124 that should be just 
enough and there wouldn't be need for questions like 'do I need to implement 
xmpp integration stuff'.

> Any interest out there for a BOSH transport for cometd/bayeux?
Well, as there are http servers with bosh support and so far the problem is 
solved via proxying/http support in xmpp servers - yes, I think there is a 
lot of interest for such solution.

> Is this the right forum/community to be asking these questions?
Yes, it is.

> If there are any similar efforts underway, then I'm happy to collaborate
> with them. But then I'm also happy to create a totally new BOSH
> implementation and would be keen to meet anybody interested in
> Collaboration.
Take a look at openfire. If you are both GPL and as you are both java - you 
may be able to share code.

> cheers

--

-- 
Respectfully
Alexey Nezhdanov