tux-droid-user

[tuxdroid-user] usleep in send_daemon_disconnect()

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

I'm itching to remove the usleep(10000) in send_daemon_disconnected()
but I want to know first: why was it here in the first place ? Same
reason as for the other usleep()s that were necessary to avoid busy
looping before select() was used ?

	Damien

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

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

On Sat, 02 Jun 2007 08:16:06 +0200, neimad <ror...@gm...> wrote:

> I'm itching to remove the usleep(10000) in send_daemon_disconnected()
> but I want to know first: why was it here in the first place ? Same
> reason as for the other usleep()s that were necessary to avoid busy
> looping before select() was used ?

There are 3 usleep in the code right now:
1. in id_lookup(), the RF is not connected and an id_lookup request is  
sent, usleep is used to wait for the answer that should be in the dongle  
100ms to a few seconds later, there's nothing else to do while waiting  
here so usleep maybe still makes sense, no?
2. in send_daemon_disconnected() but I don't understand what it's for,  
I'll ask rémi on Monday but I guess we can just remove it;
3. in usb_write_TuxDroid(), we first send the request to get the status,  
then the USB IC stores all data in the buffer and then it's available on  
the USB bus, usleep is meant to wait for the data here. That's the part  
I'd like to change by cutting the function in 2 parts as we can process  
some TCP stuff while waiting for the USB.

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

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

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

> There are 3 usleep in the code right now:
> 1. in id_lookup(), the RF is not connected and an id_lookup request is
> sent, usleep is used to wait for the answer that should be in the
> dongle  100ms to a few seconds later, there's nothing else to do while
> waiting  here so usleep maybe still makes sense, no?

That's ok, i guess.

> 2. in send_daemon_disconnected() but I don't understand what it's for,
> I'll ask r=C3=A9mi on Monday but I guess we can just remove it;

Ok, I'll repress my urges until then.

> 3. in usb_write_TuxDroid(), we first send the request to get the
> status,  then the USB IC stores all data in the buffer and then it's
> available on  the USB bus, usleep is meant to wait for the data here.
> That's the part  I'd like to change by cutting the function in 2 parts
> as we can process  some TCP stuff while waiting for the USB.

Agreed, we definitely need to make this asynchronous.

	Damien

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

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

On Sat, 02 Jun 2007 10:04:59 +0200, neimad <ror...@gm...> wrote:

> "David Bourgeois" <da...@ja...> writes:
>
>> There are 3 usleep in the code right now:
>> 1. in id_lookup(), the RF is not connected and an id_lookup request is
>> sent, usleep is used to wait for the answer that should be in the
>> dongle  100ms to a few seconds later, there's nothing else to do while
>> waiting  here so usleep maybe still makes sense, no?
>
> That's ok, i guess.

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, 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.

>> 2. in send_daemon_disconnected() but I don't understand what it's for,
>> I'll ask rémi on Monday but I guess we can just remove it;
>
> Ok, I'll repress my urges until then.

Rémi doesn't know neither, so you know what to do :-)

>
>> 3. in usb_write_TuxDroid(), we first send the request to get the
>> status,  then the USB IC stores all data in the buffer and then it's
>> available on  the USB bus, usleep is meant to wait for the data here.
>> That's the part  I'd like to change by cutting the function in 2 parts
>> as we can process  some TCP stuff while waiting for the USB.
>
> Agreed, we definitely need to make this asynchronous.
>
> 	Damien
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by DB2 Express
> Download DB2 Express C - the FREE version of DB2 express and take
> control of your XML. No limits. Just data. Click to get it now.
> http://sourceforge.net/powerbar/db2/
> _______________________________________________
> tux-droid-user mailing list
> tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tux-droid-user

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

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

"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 ?

> 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").

>>> 2. in send_daemon_disconnected() but I don't understand what it's for,
>>> I'll ask r=C3=A9mi on Monday but I guess we can just remove it;
>>
>> Ok, I'll repress my urges until then.
>
> R=C3=A9mi doesn't know neither, so you know what to do :-)

Done.

	Damien

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.

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

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

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

On Tue, 05 Jun 2007 18:54:40 +0200, neimad <ror...@gm...> wrote:

> 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 ?

It will pik a random one. The first tux that will get the dongle request  
will answer it's ID. This is how the RF firmware is done now. By repeating  
this a lot of times, you should get all disconnected tux lying around.
I'd like to change it so that after a request, a tux will wait something  
like 10 seconds before answering to an id_lookup again so that it's easier  
to repeat id_lookups and get all tux around.

> 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 ?

You simply can't. When initialized, both RF modules will change their  
protocol which is completely different than the initialization phase. So  
it's not really forbidden, it's a limitation of the firmware.

> 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)

As of now, you can only connect one tux to the daemon. But once we'll have  
dropped that limit, we will indeed provide a status table of all available  
tux. The idea of Rémi and Thierry was also to be able to connect multiple  
daemons together so that a client connected to one daemon will see all tux  
available on the daemon network. But I don't think this will be  
implemented soon.
And as I explained above, it's not possible to connect to an already  
connected tux in order to get information from them. I don't know if it's  
possible to scan the RF band in order to catch some patterns that would  
indicate a connected tux, without knowing it's ID. But anyway the RF flash  
memory is already overfilled so there's no chances that such a thing could  
get in.

David

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

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

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

> As of now, you can only connect one tux to the daemon. But once we'll
> have  dropped that limit, we will indeed provide a status table of all
> available  tux. The idea of R=C3=A9mi and Thierry was also to be able to
> connect multiple  daemons together so that a client connected to one
> daemon will see all tux  available on the daemon network. But I don't
> think this will be  implemented soon.
> And as I explained above, it's not possible to connect to an already
> connected tux in order to get information from them. I don't know if
> it's  possible to scan the RF band in order to catch some patterns
> that would  indicate a connected tux, without knowing it's ID. But
> anyway the RF flash  memory is already overfilled so there's no
> chances that such a thing could  get in.

Ok, thanks for these detailed explanations :-)

	Damien