Re: [tuxdroid-user] usleep in send_daemon_disconnect()

[David B. <da...@ja...>]

On Mon, 04 Jun 2007 19:32:02 +0200, neimad <ror...@gm...> wrote:

> "David Bourgeois" <da...@ja...> writes:
>
> [...]
>> I forgot something here. The daemon will start when the dongle is
>> plugged,  will open the USB connection, but the connection to tux
>> won't be  initialized. It's the client that will request to conenct to
>> tux with a  specific id or do a id lookup. So during this function,
>> the client is  connected to the dongle. Anyway, during the id lookup,
>
> I didn't get this. What do you mean with "the client is connected to
> the dongle" ? In my mind, a client is a program that connects to the
> daemon; how could it be connected to the dongle ?

Sorry, that's indeed not very clear. I meant of course that:
the client will request the daemon to request the USB IC to request the RF  
module to connect to a specific tux depending on it's id. Hum, that's not  
clearer actually, the chain is too long ;-)
So the daemon is started as soon as you physically connect the USB cable  
(udev or start the daemon manually.) But the RF connection between the  
dongle and tux is not started yet. The daemon will never initialize an RF  
connection by itself (unless we find a good reason to do so). The client  
will connect to the daemon and request it to initialize the RF connection  
to a specific tux (with the id as parameter) or do the id_lookup in which  
case the id which is returned by the dongle will be sent back to the  
client so it can use it to request a connection.

>
>> there's nothing  else to send back to the client but the client might
>> send another request  to the daemon (though I don't have an exmaple on
>> hand yet but we may find  the need sometime). So I'll probably cut it
>> in 2 parts like a normal tux  command.
>
> Why allow the connection of clients if the id lookup is not completed ?
>
> Do you mean that the id lookup is *triggered* by the connection of a
> client that specifically requested to talk to a given Tux ? If so,
> okay, but then the client should await for an ack from the daemon
> ("ok, i've found the Tux you requested, proceed") or a nack ("sorry,
> no such Tux here").

Yes, that's what I meant. The connect_to_tux(id) function of the daemon is  
triggered by the client and the above ACK will be returned. The  
id_lookup() function is also triggered by the client and the ACK will  
contain the id that has been found or a nack is no tux is found. By the  
way, the id_lookup function can only find an unconnected tux. Practically  
that means that you switch on your tux, plug the dongle, the RF modules  
don't connect yet, id_lookup() will return the id of your tux and  
connect_to_tux(id) will initialize the RF connection. Once the client kows  
the id of your tux, you can skip the first step.

I guess you should get the point now. If you think about modifications or  
improvements, they're welcome of course.