Timeouts in transfers

[Bas van Dijk-2]

Hello,

I'm the author of the high-level Haskell binding[1] for libusb-1.0. I
have a question regarding timeouts in transfers:

The documentation for 'libusb_bulk_transfer' and
'libusb_interrupt_transfer' states:

"...Also check transferred when dealing with a timeout error code.
libusb may have to split your transfer into a number of chunks to
satisfy underlying O/S requirements, meaning that the timeout may
expire after the first few chunks have completed. libusb is careful
not to lose any data that may have been transferred; do not assume
that timeout conditions indicate a complete lack of I/O..."

Does this apply to both reads and writes? So if I do a bulk read and a
timeout occurs can I still expect 'transferred' number of bytes in my
data buffer. And if I do a bulk write and a timeout occurs can I still
expect that 'transferred' number of bytes have been written?

And does this also apply to control transfers?

Thanks,

Bas van Dijk

[1] http://hackage.haskell.org/package/usb

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Hans Petter Selasky]

On Thursday 22 October 2009 23:23:33 Bas van Dijk wrote:

> Hello,
>
> I'm the author of the high-level Haskell binding[1] for libusb-1.0. I
> have a question regarding timeouts in transfers:
>
> The documentation for 'libusb_bulk_transfer' and
> 'libusb_interrupt_transfer' states:
>
> "...Also check transferred when dealing with a timeout error code.
> libusb may have to split your transfer into a number of chunks to
> satisfy underlying O/S requirements, meaning that the timeout may
> expire after the first few chunks have completed. libusb is careful
> not to lose any data that may have been transferred; do not assume
> that timeout conditions indicate a complete lack of I/O..."
>
> Does this apply to both reads and writes? So if I do a bulk read and a
> timeout occurs can I still expect 'transferred' number of bytes in my
> data buffer. And if I do a bulk write and a timeout occurs can I still
> expect that 'transferred' number of bytes have been written?
>

Hi,

When a timeout happens the USB host will simply deschedule the active transfer
descriptor(s) on that endpoint. You can assume that after a timeout the data
toggle value is undefined, and a clear-stall would technically be required to
not loose any data or re-sync the protocol. Typically you don't get to know
how many bytes were transferred before the timeout.

> And does this also apply to control transfers?

Does not apply for control transfers. They are self-syncing.

--HPS

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Bas van Dijk-2]

On Fri, Oct 23, 2009 at 9:19 AM, Hans Petter Selasky <hselasky@...> wrote:
> Typically you don't get to know how many bytes were transferred before the timeout.

Does this mean the documentation regarding timeouts I quoted earlier
is incorrect?

http://libusb.sourceforge.net/api-1.0/group__syncio.html

The reason I ask is that in my Haskell binding I currently have the
following functions:

> readBulk :: InterfaceHandle -> EndpointAddress In -> Timeout -> Size -> IO B.ByteString

> writeBulk :: InterfaceHandle -> EndpointAddress Out -> Timeout -> B.ByteString -> IO Size

So readBulk returns the array of bytes read and writeBulk returns the
number of bytes written. When the underlying libusb_bulk_transfer
returns an error code I convert it to an Exception and throw it. This
means that when a timeout occurs an Exception is thrown and the caller
of readBulk or writeBulk can't see how many bytes where read or
written.

The documentation I quoted earlier got me doubting if this behavior
was correct. If after a timeout 'transferred' does actually contain
the number of bytes read or written before the timeout, I think I have
to change the types of read- and writeBulk to:

> readBulk :: ... -> IO (B.ByteString, Bool)
> writeBulk :: ... -> IO (Size, Bool)

where the Bool indicates that a timeout occurred. This allows a user
to observe that a timeout occurred and at the same time do something
with the bytes that were read or written.

Thanks,

Bas

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Alan Stern]

On Fri, 23 Oct 2009, Hans Petter Selasky wrote:

> Hi,
>
> When a timeout happens the USB host will simply deschedule the active transfer
> descriptor(s) on that endpoint. You can assume that after a timeout the data
> toggle value is undefined, and a clear-stall would technically be required to
> not loose any data or re-sync the protocol.

While technically that's true in general, in fact it applies only to
OUT transfers in the case where an ACK packet was lost just before the
transfer was cancelled.  This is a rather unlikely combination of
events.

>  Typically you don't get to know
> how many bytes were transferred before the timeout.

The conditions apply here.  In practice it should be safe to assume
that the value reported by libusb is accurate.

Alan Stern


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Hans Petter Selasky]

On Saturday 24 October 2009 00:08:34 Alan Stern wrote:

> On Fri, 23 Oct 2009, Hans Petter Selasky wrote:
> > Hi,
> >
> > When a timeout happens the USB host will simply deschedule the active
> > transfer descriptor(s) on that endpoint. You can assume that after a
> > timeout the data toggle value is undefined, and a clear-stall would
> > technically be required to not loose any data or re-sync the protocol.
>
> While technically that's true in general, in fact it applies only to
> OUT transfers in the case where an ACK packet was lost just before the
> transfer was cancelled.  This is a rather unlikely combination of
> events.
>
> >  Typically you don't get to know
> > how many bytes were transferred before the timeout.
>
> The conditions apply here.  In practice it should be safe to assume
> that the value reported by libusb is accurate.

Isn't that dependant on the OS which libusb is used on? Or are you just
thinking about Linux?

--HPS


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Alan Stern]

On Sat, 24 Oct 2009, Hans Petter Selasky wrote:

> On Saturday 24 October 2009 00:08:34 Alan Stern wrote:
> > On Fri, 23 Oct 2009, Hans Petter Selasky wrote:
> > > Hi,
> > >
> > > When a timeout happens the USB host will simply deschedule the active
> > > transfer descriptor(s) on that endpoint. You can assume that after a
> > > timeout the data toggle value is undefined, and a clear-stall would
> > > technically be required to not loose any data or re-sync the protocol.
> >
> > While technically that's true in general, in fact it applies only to
> > OUT transfers in the case where an ACK packet was lost just before the
> > transfer was cancelled.  This is a rather unlikely combination of
> > events.
> >
> > >  Typically you don't get to know
> > > how many bytes were transferred before the timeout.
> >
> > The conditions apply here.  In practice it should be safe to assume
> > that the value reported by libusb is accurate.
>
> Isn't that dependant on the OS which libusb is used on? Or are you just
> thinking about Linux?

While I don't know for certain, it seems quite likely that the toggle
would be okay on any OS -- that is, I can't think of any way to cancel
a transfer safely while losing track of the toggle value.

The part about the number of bytes transferred might not be true under
OS's other than Linux.  I don't know.

Alan Stern


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Daniel Drake]

Bas van Dijk wrote:
> Does this apply to both reads and writes? So if I do a bulk read and a
> timeout occurs can I still expect 'transferred' number of bytes in my
> data buffer. And if I do a bulk write and a timeout occurs can I still
> expect that 'transferred' number of bytes have been written?
 >
> And does this also apply to control transfers?

Yes and yes - your API needs to reflect this property of libusb's API.
Also remember that cancellation is no different, you can cancel a
transfer and the data still might have been partially transferred.

Daniel


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel

[Bas van Dijk-2]

On Sun, Oct 25, 2009 at 4:40 AM, Daniel Drake <dsd@...> wrote:
> Yes and yes - your API needs to reflect this property of libusb's API.

Thanks, I will update my API.

> Also remember that cancellation is no different, you can cancel a transfer and
> the data still might have been partially transferred.

You can only cancel asynchronous transfers right? At the moment my
binding only supports synchronous transfers.

Are there any other return codes besides LIBUSB_SUCCESS and
LIBUSB_ERROR_TIMEOUT where 'transferred' still has meaning? In other
words can I still throw an exception (and thus loose information which
or how many bytes were transferred) when an error, other then the
above, occurs?

Thanks,

Bas

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Libusb-devel mailing list
Libusb-devel@...
https://lists.sourceforge.net/lists/listinfo/libusb-devel