[Nice] API thoughts

[Dafydd Harries]

Ar 15/04/2008 am 18:14, ysgrifennodd Kai.Vehmanen at nokia.com:
> Hi,
> 
> On 11 April 2008,  Dafydd Harries wrote:
> 
> >Our current idea is to have a new pair of agent methods:
> [...]
> >  GMainContext *
> >  nice_agent_make_recv_context (
> >      NiceAgent *agent,
> >      guint stream_id,
> >      guint component_id,
> >      NiceAgentRecvFunc func,
> >      gpointer data);
> [...]
> >The first would create a GMainContext with a GSource for each 
> >of the indicated stream's candidates, suitable for a GstSource 
> >to run in a mainloop. This provides the ability to stop 
> >waiting at any time using g_main_loop_quit ().
> 
> ... or I guess a set of GSources related to one stream/component
> (multiple
> candidates may share the same socket)?
> 
> In principle this sounds good (in fact
> 'agent.c:priv_attach_new_stream()'
> already creates the GSources this way), but I'm a bit worried about 
> how this works for clients which don't want to use different threads
> for diffenrt stream/components.
> 
> Could we somehow support both models? Or is there a way to run
> a set of GMainContexts in a single GMainloop (without writing
> a custom GSource for this purpose)...?

Oh, perhaps I wasn't clear. I absolutely want to have a good API for
single-threaded applications too.

> >  GMainContext *
> >  nice_agent_make_shared_context (
> >      NiceAgent *agent);
> [...]
> >The locking should be quite straightforward, I think.
> 
> Hmm, yes, this should be doable. Although the locking has
> to be done very carefully (inbound STUN messages affect agent-wide
> state in many ways, see conncheck.c:conn_check_handle_inbound_stun()).

Well, I was thinking that the initial approach could just be to make any
handling of inbound STUN packets mutually exclusive. We can make the locking
finer later, or perhaps look at using some kind of lock-free update algorithm.

> >I suspect nice_agent_recv_sock () and nice_agent_poll_read () 
> >should be removed.
> 
> Yep, agreed. 
> 
> One alternative would be to expose the socket descriptors for 
> all stream/components to the client, and then provide 
> thread-safe nice_agent_run() and nice_agent_recv_sock() methods
> (latter would work in a nonblocking fashion, called after 
> nice_agent_run()). The client could then either a) poll all sockets 
> from a single thread, or b) have a single thread for control and 
> then one thread per stream/component. Under the hood, this would of 
> course require similar changes to libnice implementation (e.g. locking 
> would be needed).

Ah, so the client would run nice_agent_run () in a loop in this case? That
could work. I'm more keen to provide a good callback-based API, but exposing
the file descriptors might make sense for mainloop-impaired programs.

-- 
Dafydd