Hello Jim,

Thanks for your comments. Please see my response inline.

[...]

> A few comments:
>
> - It could use some more clarification for whether transmission is
>   blocking or nonblocking, i.e. whether the dongle should wait for
>   transmission to complete before returning a response.
Yes. I guess it could use some clarification. I would tend to favor 
blocking TX, so that the device can return the status of the TX. This is 
especially true when use auto-acknowledgments: the sender can know if 
the receiver actually received the packet or if the transmission failed.
Also, without any flow control logic, I believe the network stack would 
flood the device at a speed that is higher than TX speed (thus leading 
to very high packet loss). Unless the device warns the host when it's 
internal buffer is full.

> - What happens if there's no response?  For example, if the dongle
>   sends "receive block" but never gets a response from the host,
>   should it keep sending them anyway?  How long should it wait before
>   deciding no response is coming back?  Similarly, what should each
>   side do if a bad response comes back in either direction?
Currently, there is some timeout mechanisms (on both the driver and the 
device), so as to recover from this situation. I should probably add 
some default timeout values in the text, either based on the current 
ones or by computing maybe more "optimal" values depending on the 
communication speed with the device.
I'm not sure what you qualify as a "bad response":
- if it's an status indicating "FAILURE", the error_code provides 
information on the reason of the failure (when possible). This can be 
reported by the driver to the system.
-  when the host or the dongle response does not match the request, the 
requester should detect the mismatch. If the "bad response" occurs after 
the cmdId, I guess there is two possibilities: the response is shorter 
than the expected response, a timeout will kick in, and the request will 
fail. If the response is of equal or longer size than the expected 
response, I guess it gets misinterpreted by the receiving end.

So far, I haven't seen any of these two failure scenarios.

> - This protocol seems terrible for throughput due to turnaround
>   latency.  USB, for example, will necessarily introduce a one frame
>   (1ms) or one microframe (125μs) latency every time you're waiting 
> on
>   a direction change.  The FT2232 (used in the Econotag) will also 
> add
>   a 16ms latency before flushing short transfers to the host, by
>   default.  So any time you transmit a packet, you could end up
>   waiting an extra 16ms for the response.  Instead of trying to tweak
>   those types of details on a per-device basis, it would be better to
>   not require a per-packet direction change in the protocol.  You
>   could add fancy pipelining that allows multilpe outstanding
>   unacknowledged requests, or maybe just add some "transmit
>   unacknowledged" and "receive unacknowledged" style commands
>   that don't require waiting on a response.

I don't know much about the USB protocol, so I take your word for it. I 
don't think the "fancy pipelining" is easily possible, and I'm not sure 
if it would be desirable. Currently, the kernel process only one packet 
at a time. It would require some internal queuing mechanism within the 
device.
The unacknowledged requests, for both "transmit block" and "receive 
block" commands seems like a very good idea. Actually, I can't seem to 
find a scenario where the device would required a "receive block" 
command to be acknowledged. I'll try to implement it soon in order to 
check how it behaves, and I'll post the results here.

Again, thank you for all your valuable comments.

Regards,
Tony

------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel

Reply via email to