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

[neimad <ror...@gm...>]

"David Bourgeois" <da...@ja...> writes:

[...]
> 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.

Yes, thanks for the clarification.

What if there are several Tuxes around one's computer ? Will the
daemon return a list of available IDs, pick the first one, or pick a
random one ?

What if a client wants to connect to an already connected Tux ? Is it
forbidden (as you said) so as to ensure exclusive access, or are there
other reasons ?

What about sending to the client a list of *all* Tuxes with their
connection state (connected, not connected) ? (assuming it's not
forbidden to request a connection of an already connected Tux, of
course)

	Damien