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