[PATCH 4/6] P2P: Add p2p group formation tiemout after p2p invitation result

[Johannes Berg]

On Mon, 2011-06-27 at 10:56 +0200, Jean-Michel Bachot wrote:

> > Is there a particular reason for this change? Please note that this
> > catches only the case where a persistent group is being reinvoked
> > between devices that support persistent reconnect. Without that,
> > persistent group re-invocation would follow different path due to user
> > acceptance being required.
> >
> Indeed , this timeout has been set only for the case a persistent group 
> is reinvoked between devices
> that support persistent reconnect. The reason of this timeout is that it 
> allows to report the GroupFinished
> signal on D-bus interface upon the GO formation timeout expiration (like 
> for the GO negocation). If timeout expires, it means that
> a connection failure occurs . It can be for example  the 4  way 
> handshake that fails. Issue is that no event exists in current 
> implementation
> that reports failure between the Invitation succes and the real p2p 
> connection establishment.
> I believe it would be great to implement this kind of event, for example 
> a 4-way handhake failure to inform upper layer ... . Would  it be correct ?

I'm digging through our tree and found this.

Is there any reason this can't be implemented in the application that
started or uses the group? It should have allowed the peer to do
reinvoke the group, so it knows that this is going on, and then if the
peer never connects it's a matter of policy whether or not the group
keeps running or not, right? So it's not something that should be
hard-coded? And since the application knows when a peer connects it can
track this?

Am I missing something?

johannes