[avahi] when can avahi_entry_group_commit return "Bad state" ?

[Julien PUYDT]

Julien PUYDT a écrit :
> Lennart Poettering a écrit :
>> On Tue, 02.09.08 19:00, Julien PUYDT (julien.puydt at laposte.net) wrote:
>>
>>>>> I have a bug where I get published correctly at first, but don't manage 
>>>>> to update my information later : avahi_entry_group_commit returns "Bad 
>>>>> state"...
>>>>>
>>>>> What should I do after/before 
>>>>> avahi_entry_group_update_service_txt_strlst so that my data is updated?
>>>> the Avahi client will return AVAHI_ERR_BAD_STATE if you commit an
>>>> entry group whose connection to the server is dead.
>>> Hmmm... and how do I know if the connection to the server is dead? 
>>> Shouldn't I know from the callback client?
>> You can find that out with avahi_client_get_state(). If the state is
>> any of AVAHI_CLIENT_S_REGISTERING, AVAHI_CLIENT_S_COLLISION and
>> AVAHI_CLIENT_S_RUNNING a connection tot he Avahi daemon is available.
>>
>> If the state is AVAHI_CLIENT_S_RUNNING the host name is well
>> established and you may install entry groups which refer to the host
>> name. If the state leaves AVAHI_CLIENT_S_RUNNING you should remove
>> your entry groups since the hostname they internally might refer to is
>> no longer established.
>>
>> Browsers/resolvers may be kept during the whole time we are in one of
>> the aforementioned AVAHI_CLIENT_S_xxx states.
>>
>> This is documented on http://avahi.org/download/doxygen/main.html
>> under "How to Register Services".
>>
> 
> Registering services is ok, precisely because it's well documented.
> 
> Updating services isn't that well ; I'm trying to use the 
> avahi_entry_group_update_service_txt function:
> http://avahi.org/download/doxygen/publish_8h.html#9f805d25a03009baf606c14a4d7cb3dc
> 
> And I don't manage to get it to work ; I added g_print statements to 
> follow the client and entry group state change, and to my functions 
> which deal with empty group ; here is what it prints :
> 
> AVAHI_CLIENT_S_RUNNING
> AVAHI_ENTRY_GROUP_UNCOMMITED
> avahi_entry_group_add_service_strlst: OK
> avahi_entry_group_add_service_strlst: OK
> avahi_entry_group_commit: OK
> avahi_entry_group_update_service_txt_strlst: OK
> avahi_entry_group_update_service_txt_strlst: OK
> avahi_entry_group_commit: Bad state
> AVAHI_ENTRY_GROUP_REGISTERING
> avahi_entry_group_update_service_txt_strlst: OK
> avahi_entry_group_update_service_txt_strlst: OK
> avahi_entry_group_commit: Bad state
> avahi_entry_group_update_service_txt_strlst: OK
> avahi_entry_group_update_service_txt_strlst: OK
> avahi_entry_group_commit: Bad state
> AVAHI_ENTRY_GROUP_ESTABLISHED
> avahi_entry_group_update_service_txt_strlst: OK
> avahi_entry_group_update_service_txt_strlst: OK
> avahi_entry_group_commit: Bad state
> 
>  From this I gather :
> (1) that whenever my updating function gets called, it triggers the 
> display of :
> avahi_entry_group_update_service_txt_strlst: OK
> avahi_entry_group_update_service_txt_strlst: OK
> avahi_entry_group_commit: Bad state
> 
> FIX: I certainly call it too soon, and should guard against calling it 
> before AVAHI_ENTRY_GROUP_ESTABLISHED is obtained (using 
> avahi_entry_group_get_state)
> 
> (2) after AVAHI_ENTRY_GROUP_ESTABLISHED is obtained, I don't get why I 
> still have problems.

The *only* example of service updating I have is
client-publish-service.c, which does a service renaming and hence has to
  reset and publish again. That is not my case : the name is constant, I
just change some data attached to it -- a case about which the doc (yes, 
I did read it!) says what not to do (free the entry group, which 
prevents protocol optimisations), but not precisely enough what to do.

Would it be possible to have a working example of a use of
avahi_entry_group_update_service_txt ? I fear I'll have to disable avahi 
in the upcoming ekiga 3.0...

Snark on freenode&gimpnet