WWDC2004 Session 500

Transcript

Kind: captions
Language: en
welcome so I was thinking about this
session over the weekend and it occurs
to me that I've been speaking of the USB
session since 1998 when I had more hair
and what was notable about 1998 for me
was that that was probably the last year
that Mac week was published in print
form and Max a knife wrote an article
that said they absolutely coming up to
WWDC this session you've got to go to is
USB and the room was absolutely packed
now the rooms not packed today and
actually I think that's okay because it
really refers or relates a lot to the
maturity of the product now we're going
to talk a lot about where we're going
we're going to talk about some new
things that we have but let's look at
where we've come since 1998 at the dawn
of USB when USB really only had two
major devices that were well supported
well engineered and there were many of
them you know what they were keyboards
and mice so since then we've come up
with mass storage devices modems
printers networking devices cameras
digital still cameras video cameras and
so forth so just as an overview for
today I want to give you a progress
report on what we've been doing what's
ahead we're going to have some
presentation on remote USB we have an
i/o lab tomorrow the only thing that I
would say about this i/o lab is that it
will be all day long in the developer
relations developer technical support
lab except for the USB and firewire
feedback form wouldn't make much sense
to have you go to the lab when you could
come and give us feedback and then the
beginning of the day on Thursday
Thursday night we have the USB firewire
Bluetooth rendezvous plugfest at the
campus during campus bash it's on top of
the cafeteria in aisle four so what you
learn today will we will focus on what
we've been doing over the past year in
Jaguar we're going to talk about the
issues that affect you as developers and
of course we want your feedback at the
end of the session to learn even more
and really the most important thing is
right way to write code the right way to
wait drivers the right way to design
devices that are going to get you the
best best behavior but there are some
techniques that you can use to match
your devices to drivers without writing
any code at all these code lock X just
allow you to split in the vendor and
product ID and match up to a device
automatically so as you know right now
every single CPU we ship comes with
high-speed USB 2 0 the emacs the imax
the power books powermax etc the notable
thing is that we've added ehci host
controller support that's how we get
high speed USB we'll talk later on and
what we're doing to add even more
controller support so i'll leave that
surprise for them there are a number of
robustness fixes that we put in the 10 3
update and one thing that's very cool
for us is that if you remember where we
got to in the very final days of Mac OS
9 19 2 9 22 as we added its support for
USB you ki s devices so that you would
automatically see them on a desktop
machine if you plug in a USB device a
USB enabled you UPS it would
automatically appear as a battery device
and that kind of support is now present
as well so with that let me bring up for
narrower beyond release I will be
talking about some new API and that we
have added two hours family some changes
that we have made to existing class
drivers some of them based on feedback
that we got at last year's Developers
Conference and finally I'm going to give
you an overview of new class drivers
that we have added especially we've
added support to the video device class
specification the CDC Ethernet devices
are now supported and there's some
changes that we've made there as well
and finally we've added
support for uhci controllers one of the
new IP is that we have implemented is
the time stamping of USB reads as most
of you may know the callbacks from your
drivers are issued on the USB work loop
and this work loop can be delayed
depending on whether other high priority
threads are running in the system so if
you're you if the USB transaction
completes on the bus and the hardware
notifies us at a certain time there
could be a latency or some amount of
milliseconds before your driver gets
that call back and this is what we call
the workload latency issue we discovered
that some clients including our head
driver would sometimes like to know at
what time the hardware issued the
interrupt and our fill their interrupt
process that interrupt so that it could
take care of any delays that happen
before it's called back position so we
went ahead and added this new API it's
very similar to one of the existence I
Oh USB pipe read api's and only
difference is as its i lighted is that
we now have a I ousd completion with
timestamp parameter instead of just a
regular IO USB completion this time
stamping is currently implemented into
your tiger seed and it's only
implemented for interrupt and bulk reads
we saw no reason to implement it for
right but if you have a good and valid
reason to do it let us know through the
USB list or the feedback forum or down
at the hardware aisle lab tomorrow and
thursday and and we'll consider and we
might added the IO us ly completion with
timestamp looks as though in the screen
and the action is the different
parameter there an ADA is an iou SB
completion action with timestamp and the
way it works is that your action routine
or your callback essentially gets a new
parameter in the past you've gotten of
course the status the buffer size
remaining and now you're going to get
the timestamp again the timestamp is
that time not when the controller
completed the transaction but where our
filter interrupt routine which is our
primary interrupt routine actually
receive that interrupt so there's a
little delay there between the hardware
and the filter interrupt routine running
we now have the an IO USB composite
driver instead of an apple USB composite
driver it is the same code however we've
changed the name because now we
guarantee binary compatibility in the
future so we had recommended in the past
that if you needed the behavior of the
apple USB composite driver that you go
ahead and download the family sources
from darwin and do a copy and paste and
generate your own kernel extension now
we're allowing you to subclass that
driver so you have to write less code
and any bugs that we fix it even though
it's a fairly straightforward driver
you'll just get by default instead of
having stale code you would use this
driver if you need to customize the
startup behavior of your device the
compositor e device the composite driver
all it does is essentially generate a
set configuration on the bus and the
family actually instantiate the USB
interfaces for your device however
sometimes the set configuration is not
enough anyone do want to do something
else so you go ahead and subclasses
driver and add your code and and that's
it it is also or it also can be used to
solve what we call that route driver
dependency problem and roads will talk
about this in a little bit but
essentially by overriding that that
country
duration method of the driver you'll be
able to to solve this this problem now
let me review how USB from user space
works because one of the other changes
that we have made to existing drivers is
that we're going to allow you to
subclass the device user client or the
interface user client so as you might
recall in USB from user space word works
like this you have an application that
it might be a driver itself that opens a
connection to the i/o USB lib and create
either an i/o USB device interface or on
Io USB interface interface so is that
really quickly that then connecting to
the colonel through the interface user
client kernel extensions again device or
interface user client and that user
client talks to our kernel objects
either the pipe or the interfaces and
then sends a the transactions down to
the USB controller and out the bus we
thought and again from some requests
from developers that it would be nice to
allow you to intercept that data going
to the colonel and out of the colonel so
by allowing you to subclass the user
client you can insert your subclass like
I've shown here in the slide and then
I've call that come on their score X X
underscore interface user client and you
will have access to the stream going to
and from the the colonel so that is
handy if you need to modify the behavior
implementing the user client subclass is
actually a two-step process because of
the way I that I ok it opens the
connection to the user client object
first of all you have to have a property
in your device or your interface that
tells I ok
what object to instantiate when a
connection from user space is requested
in i okayed it is called the io user
client class and of course you want your
subclass to only affect your device on
nobody and not somebody else's device so
you have a code length text and we have
examples of how to write code like text
you know in our examples in in your
system and we've been doing this for in
you know the last three or four WD sees
you have a vendor specific specific
matching to your device like I've shown
here with an ID vendor an ID product the
class is the apple USB merge node class
and that is a class that allows you to
merge a property into your provider and
then the class name or the the property
name that you're going to merge is the
IO USB user client class and the value
for that property is the name of your
class that I Oh kid needs to instantiate
when a connection is open to it the IO
USB family will take that I you use the
user client class and converted and put
it into your node as the IO user client
class that I yo kid needs to use I have
an example here of sub classing the
interface user client a class
declaration for it it's very
straightforward in this case for this
example I'm just going to override the
control request in method of the
interface user client class this is a
method used when you want to read issue
a device request to the device so it's
from device to host this implementation
of that method shows how to how I go
ahead and intercept the USB stream first
of all at the top I need to decode the
parameters of the method into device
request fields and
you can look at the USB family sources
to see how we did it but it's you know
just like that they're all all the
different fields are packed and encoded
into you in 32 then since it's a request
from the device to the host we first
issue the code to our super class and I
will cause the transaction to go out on
the on the bus and since it's a
synchronous transaction it will return
when that has completed once it has
completed in this example I want to know
whether the control request was a
printer class-specific get device ID
request to interface 0 alternate setting
serial so I go ahead and check those
parameters and if it is then I have I
can do something with it in this example
I don't do anything but I could examine
the buffer value and see what the device
return and and do something to it again
at the end of course you gotta remember
to return the earth at your superclass
returned in the past the user clients
work calls actually I owe USB device
user client and I you use the interface
user client however they were not
successful and this goes against
everything that we've told since the
beginning that if it was high yo USB it
means it took it was a plateau of course
the the headers were not available for
you so you really couldn't subclass it
and even if you copy the headers they
said right there this is not intended to
be software anyways we're fixing that
now what that means is that we're going
to guarantee binary compatibility in the
future if you subclass the user clients
and there is sample code available that
is the complete example that i just
showed that compiles and work a couple
of miscellaneous updates in developing
the video digitizer to support the USB
video class specification i realized
that there were some api's that were
exposed in the colonel but were not
exposed to user space
and so I went ahead and implemented fine
next Association associated the
scripture and findings of interface and
those of you do an isochronous drivers
forum user space might might find it
handy to to use those to decode that the
scriptures instead of having to do it
all by hand one part that is really not
an external API change but it's an
internal implementation in the family is
that the family now uses the command
sleep and command wake up i okayed
functions in the past those of you who
have seen the the sources we simulated
synchronous commands to the USB
synchronous transactions by using the io
sinker object from i/o kid and that
allows allowed us to send a command to
the USB bus and sit and wait for that
command to complete and then called our
client that's how we simulated
asynchronous command on an asynchronous
voice but I you think ur has now been
deprecated in terms in favor of command
sleep and come and wake this is a lot
friendlier to the system it uses less
resources it allows other things to run
in when you're commanded when you issue
the command sleep which essentially puts
the threat to sleep and it also solves a
bug that we see every so often and that
we've talked in previous WWDC s and that
is the problem that you cannot issue a
synchronous command from your call back
because you're on the io USB work loop
and if you do you'll deadlock the bus
and nothing will work from there on
there was no you could do that in in
previous versions and you get nowhere or
anything by using command sleep you
inside we will know that you are on the
work loop and will issue an error right
away an immediate error of ki USB sync
requests on work look thread
to you so you'll know that your
synchronous request did not work and you
want that lock the bus and it will save
us all some time through the open source
process this past year we received a
submission to support the uhci
controller as you know we support ohci
from way back then and last year we
added ehci controller but we've never
added support for uhci controllers
because Apple has never shipped a
machine with with such a controller we
we receive the submission we you know
tweaked it a little bit here and there
and added it to our project and it is
actually shipping and unavailable in
your tiger seed the purpose of this
slide is just to show you that the open
source submission really does work and
that we take all submissions seriously
so we again encourage you to download
our sources and if you use them for
something that other people can can use
send it back to us and we'll take it
from there in terms of new device class
support as I mentioned we have several
or a couple new device class drivers
actually the 1033 update included
support for USB CDC Ethernet devices in
the past this was just sample code that
was available on request from DTS but
with 10 33 it was became part of the
system however as I'm going to mention
in a couple of slides for tiger we now
have a new USB CDC driver that supports
modem and Internet CDC devices and some
of you know last August the USB
implementers forum approve version 1
point of the USB video class device
specification and Tiger is going to add
support for some of that specification
City c-class devices we've added with
has support for them since the beginning
from the driver in mac OS 10 while
essentially ported from our mac OS 9
driver it has worked well it's a device
driver as opposed to an interface driver
it uses a fairly simple buffering model
and it worked well for low bandwidth CDC
devices however as new devices with
higher bandwidth and with multiple
interfaces have come into the market
recently all of them CDC compliant and
we realized that there was a need to
revamp this driver so we've gone and
created this new driver that is in your
tiger Sid feed it supports devices that
have multiple interfaces not just the
data interfaces but maybe mass storage
and others it also has a multiple
buffering model to allow us to better
support the high bandwidth devices the
new driver architecture essentially
looks like this the device driver level
we still have a device driver but it's a
very simple device driver that is
essentially just the equivalent of the
composite driver it creates the
interfaces and then it excuse me it
causes the either the ACM driver for low
bandwidth devices to be instantiated for
those interfaces or the ECM driver for
the high bandwidth devices so that works
really well an example of how that cdc's
devices have changes for example the
third-generation cell phones that can
have a whole series of USB interfaces
and having the old drivers that assume
that all the interfaces were where the
data communication interface would
certainly not work in in this case you
could have a hitter interface for the
keypad you can have mass storage
interface to access the card for the
pictures are stored of course you can
you can have the the data interfaces you
can have the the Bluetooth interfaces
and perhaps even audio interface
in there so you can see that CDC devices
have come a long ways and that is the
reason for our change the USB video
class was approved like I said last
August and I've been working with the
device working group for web before that
the base specification itself is video
format agnostic it just tells you what
kind of interfaces or what kind of
functions video functions that device
supports of how still image is supported
whether its bulk stream or I socks
streams that are supported how the host
and on the device negotiate what kind of
streams Susan and at what bandwidth it's
very general in those terms the base
pack itself is followed by several
payload specifications that tells the
driver writer what the format of the
data that is encapsulated in those
strings looks like and how the all the
information in there is to be decoded
there's payload description
specifications for y UV 422 a flavor y
ue 422 and a flavor of motion jpeg and
those are mainly for web camera
situations DV is over us beast expecting
their mpeg-1 and mpeg-2 so I encourage
you if you're thinking about video class
devices to go and make a video class
compliant device Tiger will have support
for the USB video class specification by
using a video digitizer that lives a
library quicktime quicktime USB be VDC
digitizer component the software will
support web cameras either in the motion
jpeg or the y UV 422 formats it supports
balck and isoka streams and there's
right now
cameras are shipping with with both kind
of streams even though the manufacturers
actually don't make a big deal that it
is that they are very sick class
compliant devices but they are shipping
there will show you in a little bit the
still still image support will be
provided through the image capture
framework so that it is seamless to the
user you just look like another source
of still pictures the spec actually is
going son raveesh from ongoing revisions
for to further clarify the DV support so
there is no DB support for USB video
class devices in Tiger excuse me a
second describing a video class device
can be a little tricky because they can
have and in this example of a digital
camera or a video camera you can have
the video class interfaces you could
have audio interfaces for the microphone
you can have mass storage interfaces for
the picture card that is in the machine
so they're needed a way to and I forgot
it to describe in terms of the USB
device the scripts or how this device
looks so that whole software could
readily find the particular interfaces
that that are are of its concern and and
unused them instead of having to go
through every single interface and see
what kind of interface it is so the USB
IES came up with the interface
association descriptor and this
descriptor tells us at the device level
that it is a miscellaneous class device
with a common sub class and an interface
association descriptor protocol this
just tells us tells the device driver
that you need to look into the
configuration descriptor for the
interface association descriptor that
follows which is going to group the
different functional
interfaces and if we can go to the demo
machine i will show you how these
interfaces actually look here we have a
panasonic video class specific compliant
device and i'm going to turn it on and
start USB prober and look at the camera
right here you can see that the device
is miscellaneous common class interface
association descriptor here on the
configuration descriptor we see that
there are 1 and 2 interface association
descriptors one for the video interface
collection and ones one for the audio
collection if we disclose one of those
it just tells us that the first
interfaces interface number zero and
there are two interface and further more
than it tells us that it is the video
subclass we go down here and now look at
the audio control collection the first
interface is too and there's again to
interface for the audio control and in
the audio streaming and the class is the
audio class so it's just a way for the
device to tell us what functions it
supports and our drivers can then match
and in fact for this camera we can see
that the driver or is it has the video
control interface and the video
streaming interface and then there's the
audio apple USB audio device and engine
matching to the to those interfaces then
we have here another camera this is a
just a picture car in a digital camera
that also has a web interface and this
one is right down here and in this case
it doesn't have a microphone so there
will only be one video in a fresh
collection
but we can start a video capture
application and you can see that that
their support is real and it's there and
we are continuing to oh I didn't want to
do that so it works we're continuing to
support all the cameras that we can get
a hold of that support now is it such
that new cameras that have come in i
haven't had to change the driver at all
so we're getting there i believe that
that is the end of the demo and we can
go to the roads will now come and talk
to you about some other USB issues i
[Applause]
want to talk to you about some of the
issues that have come up in the last
year of these are issues that have come
up in our own internal driver
development and on the USB developer
mailing list i'm going to talk about
three specific things one is the what I
call the split transaction error problem
this is these are USB errors with full
speed or low speed devices attached
through a high speed hub to a high-speed
bus then another issue that's more of an
i/o kit issue but we call it apple USB
composite stole my device this is an
issue that has come out quite frequently
with third-party developers and then
another one called my device gets the
wrong config which is more rare but an
interesting solution so first we're
going to talk about the split
transaction errors what you have here is
a picture that's sort of adapted from
the USB 2.0 specification appendix a
table a dash 12 here is a what we're
going to go through here is a split
transaction between the high speed host
a high speed hub and then a full speed
or low speed device attached to that hub
so let's say the host needs to send some
data out to the classic speed device so
it first sends a start split token to
the high speed hub thing I have a
command for a classic speed device
followed by the out or setup packet
that's what the table a dash 12 will
show you followed by the data and the
high speed hub acknowledges that data
transfer now the high speed hub needs to
send the data to the device so first it
sends the outset up packet followed by
the data but in this example the device
either ignores the data does not respond
to it in any way or never gets the data
for an electrical problem or because it
is physically disconnected or for some
other reason and that happens three
times in a row so finally the host wants
to find out what happened to that
command at that data packet so it sends
a complete split command to the hub
identifies which complete split it's
looking for and gets a response of stall
from the high speed hub so that's one
example now we're going to go to another
example and compare them so in this
example this is table a dash 23 from the
USB 2.0 specification and in this
example the same same situation the host
since the start split followed by the
out or set up packets followed by the
data and gets acknowledged the high
speed hub then sends the outset up
packet and sends the data to the device
this time the device gets the data but
it doesn't like it so it returns a stall
kid later on the host wants to find out
what happened it sends the complete
split it identifies the complete split
and it gets a stall back from the high
speed hub now i'm going to show you the
other table here on the next slide I
want you to pay close attention to the
information on the left hand side of the
screen when we go back to table a dash
12 you'll notice that the left hand side
did not change let's go back to the
other one again it didn't change what
this means is that from a controller
point of view in the host we can't tell
the difference between the situation
where the device did not get the data
and the situation where the device got
the data but didn't like it so what does
your dry
ever need to do well first of all you
need to realize that stall does not
always mean stall it may mean that the
device stalled the data and it may mean
that the device didn't respond at all so
the high speed hub stalls the command
what we have done with this in the USB
family is when this situation occurs we
will return an error of ki o USB pipe
stall the first time we see it on a
particular pipe and the third time in
the fifth time and all the odd times but
on the even times we will return a
different error k io return not
responding so that hopefully if you
issue the command twice in a row one of
the two errors will cause your driver to
to know what to do with the situation
when this happens no matter whether the
device no matter which of the two
situations occurs the endpoint is halted
inside the host controller and it needs
to be cleared at least in the host end
and possibly in the device end but we
don't know that and the so the device
may or may not have a halt at endpoint
and your driver needs to figure it out
it needs to ask the device it needs to
reset the device it needs to do
something to deal with this situation
but you need to realize that this is
something that is different between us
be classic speed USB on an ohci bus and
high-speed or classic speed USB on a
high-speed bus and you need to deal with
it appropriately okay another issue that
has come up and we wanted to talk about
and this is more of an i/o kit thing but
it it's we've done some stuff to help
solve it here is the we call it apple
USB composite stole my device now what
does this mean this is this is when you
have a device driver for for an i/o USB
device nub as opposed to an interface
driver again this is something we
encourage people to use the composite
driver when they can but let's say you
have your own device driver for some
reason and you need that and so you
create a personality for your i/o USB
device and it's specified here and you
plug in your device and you open up you
with
prober and sure enough there's your
driver instantiated controlling this
device and that's great everything is
wonderful but then when you reboot the
machine you open up prober again and
this time the apple USB composite driver
is now controlling your device instead
of your own driver and if you unplug the
device and plug it back in you'll see
that your own driver is controlling it
again so you ask yourself why did the
apple USB composite driver match against
my device so you download the family
sources from Darwin and you open up the
apple USB composite target and you
notice this property Oh f bundle
required of route and you ask us on the
list or the i/o kit list well what does
that mean in the system there are
certain kernel extensions and the
colonel expect it self that are listed
with an OS bundle required property of
root there are a few other OS bundle
required properties but this is sort of
the main one these are kernel extensions
that are required to run very very very
early in the system to do things like
enable you to go into single user mode
or verbose mode that kind of thing we
want to be able to type on a keyboard
for example in single user mode so these
kernel extensions are things like the
mach text itself and the i/o kit and the
USB family and the various controller
drivers and so forth and one of them is
apple USB composite so this is a route
driver it loads very early in the system
but then there are other kernel
extensions that are not rude drivers for
example the i/o serial family or the i/o
audio family or some other family that
your kernel extension needs to link
against in order to be resolved and load
so what that means of course is that if
you have to link against the driver
that's not available at route time you
can't be available at route time so what
do you do what we came up with was a
clever solution that we call the poison
pill and in this solution you create an
interface driver for your i/o USB
interface object and here is a
personality for that driver and then
inside that
the interface driver in the start method
you just call remunerate device which
causes your device to get essentially
disconnected and reconnected from the
bus this your interface driver not being
a route driver will load once the system
is fully booted and when it causes the
device renumeration again it's like
physically disconnecting and
reconnecting the device and now your
device driver which has to hire matching
priorities and the composite device
driver will win the matching process now
this solution does have a couple of
caveats one of which is that you your
your device driver which might be a
subclass of the composite of the new IO
USB composite driver for example needs
to call set configuration with a
parameter of false to prevent io kit for
matching drivers against the interface
nubs or else you get into a loop where
it's just constantly remunerate advice
however preventing io kit from matching
the interface nubs will also prevent IO
USB interface user client from matching
which means that if you need a user
client for your device you need to do a
little more work finally I'm going to
talk about a situation that has come up
we call it my device gets the wrong
config this is where you have a device
an IO USB device that has more than one
configuration descriptor and the
composite driver does everything you
want you it's a composite device IE the
device class and device subclass are
both 0 and the apple USB composite
driver does a good job except for it
picks the wrong configuration because
the composite driver always picks the
first configuration and you want an
alternate configuration to be
instantiated for your device under
certain circumstances well you don't
need to write any code to do this you
can create a code list Colonel extension
where all you need is the file with a
personality and then the property list
and this property list specifies your
device by vendor ID and product ID as
you can
see and specifies that it won't you you
want to load the apple USB composite
bundle and instantiate the apple USB
composite class to match against your
device you then add one more property in
blue at the bottom of the list called
preferred configuration and you specify
the configuration number of the
configuration that you want and the
apple USB composite driver will then
load that configuration this same
technique of creating a code with text
can be used if you have a vendor
specific device IE the device class and
subclass or FF instead of 0 but other
than that the device really will behave
just like a composite device and you
want the apple USB composite driver to
load against this device and with that
I'm going to bring up very twycross to
talk about remote USB thanks right okay
so I'm going to talk about remote USB
what is it why you would want to do this
how it's done and then the interesting
part what it actually means to you so
remote USB what is it it's when you use
the device which is not actually
attached to your computer ah but you say
this is not USB is it well no it's
pretending to be us be however users do
it anyway so you might as well be
prepared for it remote USB why would you
want to do this well there is a user
demand users like to share their
peripherals classic example is using is
a printer they want one in the household
everyone in the household can print to
the one printer they also like to unwire
so they can be sitting comfortably on
this on their couch in the living room
print something up for their printer and
never have to get up at all except when
they actually go to get them go go to
get the printout from the printer it's
also a business opportunity you can sell
devices which implement remote USB users
will buy them from you and it's actually
quite a common
have a question and here's an example
from the USB is mailing USB is mailing
list where this guy says I'm a student I
have a project I want to cut the wire on
my USB put radio transceivers at both
ends and will it work well the answer to
that was basically no so let's think
about the problem a little more
rationally let's try using networking
concepts networking is a standard way of
getting data from here to there and we
want to get data from here to there also
decouple the transport of the data from
the data itself so if you want to do it
wirelessly don't worry that you want to
do it wirelessly do with the network and
then use a wireless network so it can be
Wireless this way so we'll use TCP
tcp/ip it being the commonly available
networking it's built into all our
machines everyone knows and loves it so
we need to think about the data flow
that's involved in USD intercept it at
some point and then send it across the
network to work to a device which takes
it and then sends it on to the actual
USB device so the data flow and you
start off at the top with the
application here's an example of
printing again you start off with the
application it sends data to the print
driver it bubbles down through the user
client and eventually ends up with a
controller and actually then ends up on
the USB bus itself reply only with the
device we thought of three interesting
places where you could actually
intercept this data basically at a very
high level at a very low level and
somewhere in between so let's think
about high level an example is in fact
airport extreme printing you the
application in this case is in fact the
print manager and the print drivers i/o
module instead of sending it to USB
sends it across the network to the
device well in this case an airport
extreme base station which sends it down
to its own USB stack to the printer
itself now doing this at a high level
has a big disadvantage in that
the application itself is required to
know what it's doing it needs to know
that it's talking to a network service
so it's incompatible with most solutions
which are out there however it has a
very big advantage and that protocols
exist to do this already in particular
the two big issues here our discovery
and session management you want to find
out what what devices are what services
are available to actually use out there
that's discovery we have lots of
interesting protocols including
rendezvous which they always like us to
plug for you and the other problem is
session management you only want one
person talking to your device at once
otherwise your device gets mightily
confused thank you so as you don't want
to get your your device mighty confused
you have to have some way of managing
who talks to the device at one time the
person talking to device is in fact a
session in networking protocol in
networking speak and you just need to
manage manage their stats session
management so we're thinking ok let's do
airport extreme let's do remote printing
with it with a USB printer we thought it
was the perfect application we actually
own the application so we can put the
knowledge of how to do this into the
application the application being the
printer driver itself and we own we own
sorry we also in the networking we only
only own the base station so it seemed
like the perfect application so we went
ahead we added the host controller we
added the USB stack we added a component
which understood a printing protocol in
this so in this case afterwards the
printing protocol which is there is he
called app sake georgette direct report
9100 fine but we found that the feature
set of this protocol was not actually
rich enough print drivers wanted to do
things such as soft resets getting of
the printer ID string
in fact getting the plantronics status
which which the protocol didn't allow
for there was some the printer module
was faked to actually help with this to
some extent and under the new print
module encounter which doesn't even
better job but still in all
circumstances it doesn't doesn't work
they'll be more about that later so
another idea we had let's try an
intermediate level in fact the user
client with the user client you're
already passing messages across a hard
boundary which is from user space into
kernel space so why not instead just
pass those messages across the network
to a device which can receive them and
do exactly what the user client on your
local Mac would do in this case send
data down to the printer sounds like a
very good idea so some extent
discovering session management already
built into this when you it is rate
through available user clients or
available in when you iterate through
available interfaces you're actually
doing discovery of some description and
when you open a device use the device
close the device that is in fact a crude
form of session management sounds like a
good idea and it still is only an idea
as far as we know no one has ever done
this so at the other end of the scale is
at a low level an example of this is the
keyspan remote USB server said every
school USB server I was very surprised
and January I walked into my cord came
up for the keyspan booth and thought oh
I was interesting they had in fact made
a device which had a USB controller
attached to the network and indeed the
at the data bubble down through the
system as usual the host control the
driver said here mr. mr. whim please
please send this data to the USB and in
fact that wind does send the data to the
USB bus USB happens to be somewhere else
this is at this very low level it's
actually quite a lot more compatible
nothing in the system actually has to be
aware
that that it is actually talking to a
remote device however there is no
existing discovery of session management
at this level so the USB idea
intercepting look at the controller
level if you designed to be very
transparent transparence to both
applications and even to text if you
really wanted to you could attach your
mouse to your USB server and control the
cursor on the screen somewhere over
there so it is very compatible keyspan
had to add some discovery they have a
little application which searches for
all these servers searches for all the
devices on them and makes them available
on a list the user can click on one and
say I want to use this now and they also
had to add some session management to
this they have various methods some of
which work for some applications like
the open print clothes some of which
don't like if you have a mass storage
device it's always attached the mass
storage driver doesn't open print and
close it opens and uses forever so
there's various methods of doing that
this means that the user experience is
not exactly as seamless as you might
want it to be so they're actually
looking at putting in some higher level
protocols say a day add a print print
server to the to listen to the USB
server or a mass storage file server
something like that just to overcome the
disadvantages being being at such a low
level well there so what does this all
mean to you there are two two very big
issues with any implementation like this
latency and throughput these quite
tightly coupled in that when your
latency increases your throughput tends
to decrease excuse me some protocols we
find a very sensitive to latency
specifically ones
where you do do action see rly you ask
the device something wait for reply
before you ask the device something
again an example is say the mass storage
protocol this you sended the command you
wait for that to be acknowledged you
send it some data you wait for the day
to be acknowledged then you ask it for
the status and the status comes back to
you at each stage you're waiting for
something if there is latency in the
system that just that just adds up and
adds up and the whole thing slows down
something you can do with this and
actually back keyspan did this is to
actually coalesce transfers going in the
same direction so in one transaction you
can send both the command and the data
you just cut out some of your latency in
the system they found that if they did
this even locally they could get up to a
five cent speed up on a mass storage
device which is interesting on if you're
having the increased latency without us
vserver the speedup is even better so
throughput tightly coupled to the
latency issue the latency goes up your
throughput goes down because of the
request response till it's sort of
problem and we find that in some cases
driver timeouts are too aggressive one
printer driver was found to have a two
second timeout now locally didn't
usually didn't tend to timeout but
across a network it was timing out all
the time if you have such an aggressive
timeout you could find that it could
happen to you locally so this is not
actually a good idea if your bus was
heavily loaded this nanos web cam was
turned on using ninety percent of the
bus the ten percent you have left works
hell of a lot slower than you thought it
was going to be your data doesn't go out
come back you timeout the user isn't
happy so a timeout switch is set to
aggressive ur not about not a good thing
another thing do use a standard
component if if it's available for
example using the Apple supplied printer
module so that it can then take the data
and send it across the network and
everything's happy and in general if
you're using a standard component we can
fix it you don't have to
but in the case of the printer we found
that the the feature set wasn't rich
enough and the particular for printer
utilities they're very picky about what
they do and they don't tend to work say
with the airport extreme printing so if
you want to D clogged the head on your
printer yes you have to go and plug in
locally it's actually not a lot we can
do about this except we can ask you to
provide feedback if you find that any
component we supply doesn't actually
meet your need then we can actually read
it at some time and eventually it will
meet your need and then everything will
be happy so some things you want to do
be standard design to a standard not to
any particular implementation don't say
it works on that system so it should
work on your system if you designed to a
standard it should work on any system
and if you did design to a standard me
doesn't work on a system then the system
vendor will probably be motivated to
actually fix it and have a standard very
good on or even have a well defined
standard some of the problems some of
the problems we're having is that there
is no standard for this or that the
standard does not define what a device
should do in this circumstance so it
does something quite unexpected for
example don't over land don't overload a
standard exists like we found that some
printer driver some printers in fact
would change their device ID string to
provide status we were expecting the
device ID string to be static so we'd
read it once send it over and never
bother sending it over again and some
printers just refused to print because
they were getting stale status we fix
that
don't expect everything so if you have a
compound or concrete device don't expect
to get all of the interfaces or all of
the devices in lockup in that compound
device just use the one that you
actually need for example you say you
had a device which was a printer a
scanner and a modem but you wanted to
print something and if the print driver
freaks out if it found the scanner
wasn't there even if you wanted to print
that could be embarrassing if you just
you just told your remote USB to
actually just attach to the printer and
not to the scanner and the modem as well
and also be optimal locally in your in
your data transfer if you if you
transfer data optimal if you need to be
transfer data optimally even just
locally well that's good and then when
you get into a situation where the
network adds its latencies you'll find
that you'll be in a much better position
for example using multiple reads or
multiple multiple transfers and using
larger transfers let the system do the
work of actually getting the data there
that I loon your your driver trying to
do all the work and one final point
which I'm not sure if it's a good thing
or not is whether you should post a read
if you have a readout standing on a
device you'll know as soon as it tells
you that it has something to say however
so that's good for your latency however
on some of the earlier systems some of
the slower systems having a readout
standing like that doing nothing uses up
a lot of the bus bandwidth and the
entire system can actually slow down
which is not a good thing so whether
this is a good thing or not is left your
functions so with this watch where
should you go for more information well
Craig is a good person to cook talk to
at least as the asking who else you
should talk to or indeed send send stuff
to our mailing list we like to hear from
you yeah we like to hear from you
and some pointers to documentation on
the web page you might be interested in
seeing this is this reference is
available somewhere I'm not quite sure
where