---
title: WWDC2004 Session 500
framework: wwdc
role: article
path: wwdc/wwdc2004-500
---

# 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