[libnice] How to properly use the function nice_agent_get_io_stream()

[silvio]

Hi,

Thanks for your help.

> Good question, my impression was that this is how g_input_stream_read()
> worked on regular TCP sockets. We should test, the goal is to match the
> same behavior.

I tested it. There is a very simple program in the appendix which
demonstrating that it reads only what is available even though the
buffer is bigger.

> You can use g_pollable_input_stream_create_source() to have a source
> that will trigger when there may be something to read.

The problem is i don't know to use it. I always think if I after reading
use a synchronous write to forward the info, it will block everything.
And if I use asynchronous write, I might end up with two things that
write simultaneously which might be a problem or i might read and read
and read till I'm out of memory. It's really hard to find out how it
works. Also i don't like polling i prefer select though i have no idea
if glib can do that.

> Yeah. It's a known problem with the PseudoTCP code, it doesn't have a
> FIN at all. The touchy thing is that we want to keep our PseudoTCP code
> compatible with Google's, and they don't have that either.

Is there nothing to be done about this. Like somehow find out if you are
connected to the same an other niceagent. Or file a bug with Google
which project is it.

>> 3) timeout
>>
>> when i kill one of the participants i see that some packets are still
>> sent from the other periodically but the other participant never fires
>> component-state-changed signal. I would except it to go into some fail
>> state after some timeout.

Is there a way to hook into the connectivity checks and see how long
they have not arrived.

silvio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.c
Type: text/x-csrc
Size: 442 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/nice/attachments/20140516/a60c1c43/attachment.c>