[Nice] libnice and pseudo tcp

[Youness Alaoui]

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/nice/attachments/20120110/c4d460a7/attachment.pgp>