[Nice] libnice and pseudo tcp

[Eduardo Bezerra]

Hey guys, wow, those were fast replies! Knowing that the contributors are
so helpful and easy to reach definitely makes a difference. Also, I didn't
know about all these many cases in which upnp wouldn't suffice, so I'm
definitely going with nice, since it seems to handle the nat traversal and
provides me the transport protocol I need.

We've just got a new toy here in the lab (an 80 quad-core nodes cluster)
and I'm very eager to play with it :) , so I'm gonna use it to run some
tests to compare the reliable communication of libnice against linux
kernel's tcp stack and will post the results as soon as I have them - I
know libnice was developed mostly for the Internet, but having some
numbers, even from a local environment, would already be nice, I guess...
In the meantime, I'll keep bugging you guys :)

Thanks!

Eduardo

On Tue, Jan 10, 2012 at 11:15 PM, Youness Alaoui <
youness.alaoui at collabora.co.uk> wrote:

> On 01/10/2012 04:41 PM, Eduardo Bezerra wrote:
> > Hi there,
> >
> > I was googling and found about libnice to write my application, which
> seems to
> > suit all my needs! The problem is that the algorithm I'm implementing
> depends on
> > having fifo, reliable channels... So, I have a few questions:
> Hi, welcome to the libnice world. I'll complement Olivier's responses with
> mine.
>
> >
> > - does the pseudotcp communication implemented in libnice ensure both
> deliver
> > *and* FIFO order?
> > - does it implement flow-control, as ordinary tcp?
> Yes, it's TCP over UDP, so it's reliable, *and* FIFO and it has this
> sliding
> window stuff and flow control and all that TCP stuff. It is used for
> example for
> doing file transfers in telepathy-gabble between google talk clients.
>
> > - do you have some test results regarding both message delivery delay and
> > maximum throughput of pseudotcp, when compared to tcp?
> No tests results unfortunately. If you happen to make some, please share
> them
> with us. But other than the pseudotcp header that gets added to the UDP
> packets
> (which should be just a few bytes), it should act the same as any TCP
> implementation.. maybe just not as optimized as the latest kernel stack.
>
> > - what about the maximum size of a message? I know that udp has a lower
> cap for
> > the length of a packet than what you can send by tcp with one single
> call to
> > write(). do you handle some fragmentation and reassembly in pseudotcp?
> UDP has a maximum size because you send stuff in packets, with pseudotcp
> (and
> TCP), there is no concept of packets, it's a continuous stream, so there
> is no
> limit.. however, there is an internal buffer, I think it was something
> like 30K,
> I can't remember, when the buffer is full, libnice will tell you how many
> bytes
> it sent, then you need to wait for the 'writable' signal before sending
> the rest.
>
> > - I do not intend to use a relay 3rd-party for communication... if two
> peers
> > cannot communicate directly, then the application just returns an error.
> Can I
> > use libnice in such way?
> If you don't call nice_agent_set_relay_info, then if peer to peer is not
> possible, it will simply fail.
>
> > - do you plan on including nat-pmp in libnice?
>
> Plan on including it, yes, plan on writing it, no. We'd be glad to accept
> any
> patches that adds that feature, but for now, we have no time/motivation to
> implement such a feature (it has never been requested before, and the
> advantages
> of having it are minimal)
>
> >
> > Sorry for all those questions, but I'm wondering if I should go for using
> > upnp+natpmp+stun+libutp or simply go for libnice and let it handle all
> the dirty
> > work :)
> upnp/natpmp aren't as helpful as you would think, in the majority of
> cases, it
> won't work, it will not handle if you are inside a NAT which is itself
> inside
> another NAT, it will not handle if you are trying to connect to someone
> who is
> inside the same NAT as you, it will not handle if you are both wired and
> wireless + 3G for example, and would not try to find the fastest
> connection path
> in such a case. And of course, it would only work when the user's router
> has
> been properly configured to support upnp/natpmp, but most of the time,
> upnp will
> not be available.
> The ICE specification doesn't even talk about upnp, but I decided to add
> support
> for it in libnice as a failsafe mechanism for those 5% of routers that make
> nat-traversal a nightmare.
> So, my suggestion is, even though I might be biased, you should use
> libnice as
> it will make your life much easier in the long term.
>
> Hope that helps, don't hesitate to ask any questions you might have.
> Youness.
>
> >
> > Thanks a lot!
> >
> > Eduardo Bezerra
> >
> > http://www.inf.ufrgs.br/~cebbezerra
> > PhD Student at the Faculty of Informatics - USI
> > Doutorando em Ciência da Computação - UFRGS
> > Mestre em Ciência da Computação - UFRGS
> > Bacharel em Ciência da Computação - UFBA
> >
> >
> > _______________________________________________
> > Nice mailing list
> > Nice at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/nice
>
>
>
> _______________________________________________
> Nice mailing list
> Nice at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nice
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/nice/attachments/20120111/83dc4eb4/attachment.html>