<div dir="ltr">No problem, glad you figured it out and there was no bug! </div><div class="gmail_extra"> <div class="gmail_quote">On Wed, Jun 11, 2014 at 9:29 AM, Francesco Massei <<a href="mailto:fmassei@gmail.com" target="_blank">fmassei@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi, I ashamedly have to inform that after two days and one night of work writing snippets and tests I found the problem, it was mine. I was bitten by an implicit integer conversion like a noob (actually, even worse, by not paying enough attention writing the building scripts). >From time to time there was a send() called without waiting the signal, and bad things were happening. Now everything seems to work fine. Thank you again for your patience, and sorry for wasting everyone's time.. Francesco <div class="HOEnZb"><div class="h5"> On Wed, Jun 11, 2014 at 6:32 AM, Youness Alaoui <<a href="mailto:kakaroto@kakaroto.homelinux.net">kakaroto@kakaroto.homelinux.net</a>> wrote: > > Hi, > > The first thing I notice is that you say you send data on transport_writable > signal. I hoep you know/understand that transport_writable will only be > signaled IF you do a send which returns less than the number of bytes you > wanted to send.. So if for example you want to send 1000 bytes, and the > nice_agent_send returned 1000, then transport_writable will not be signaled. > Either way, it doesn't seem to be your problem since you say you used a > packet sniffer and all the packets got sent. > Which version of libnice are you using? I think it would be important to > know. I believe there was an email recently on the mailing list about the > recv() function only returning when the entire recv buffer is filled, > instead of returning whatever data is available. I'm not sure, but this > could be related. I think Olivier might be able to help, but knowing the > version of libnice you are using will be required before he can determine > the cause. > If you have a way to reproduce the problem, that would be helpful too. > > Thanks, > Youness. > > > > On Tue, Jun 10, 2014 at 11:51 AM, Francesco Massei <<a href="mailto:fmassei@gmail.com">fmassei@gmail.com</a>> > wrote: >> >> Hello, >> >> I'm facing a strange issue with libnice that maybe you can help me solve. >> >> I have two peers that, using a reliable agent >> (nice_agent_new_reliable()), communicate between themselves. The first >> (let's call him "A") sends some data using nice_agent_send() on each >> transport_writable signal, the second (let's call him "B") receives >> the data in the callback set with nice_agent_attach_recv(). >> "A" always manages to send all the data, while "B", for some reason, >> receives only part of it: sometimes just the initial frames, sometimes >> nearly all of them, but it never manages to get them all. >> Right now I'm making tests running both A and B on the same machine, >> with a packet sniffer open, and: >> - "A" and "B" are both up and running, as I see they keep sending STUN >> messages to each other every now and then. >> - All the packets "A" sends are on the wire >> - If I try to send much more data from "A" (like streaming endlessly >> gibberish) eventually "B" will get everything >> - Waiting for a long time (even minutes) doesn't help >> >> The only hypothesis I can advance is that, for some reason, B waits >> some kind of ACK or SYN that will never arrive as long as A is not >> sending anything. >> >> Any idea on why is this happening and how could I solve it? >> >> Thank you very much! >> Francesco >> _______________________________________________ >> nice mailing list >> <a href="mailto:nice@lists.freedesktop.org">nice@lists.freedesktop.org</a> >> <a href="http://lists.freedesktop.org/mailman/listinfo/nice" target="_blank">http://lists.freedesktop.org/mailman/listinfo/nice</a> > > </div></div></blockquote></div> </div>