青云最近推出了云桌面功能，用户可以像使用本地计算机一样访问远程主机，支持USB重定向，不禁让我想起了2年前调试的一个开源项目USB/IP，当时还用英文写了一个总结性文档，放在这里方便以后查看。

                     USB/IP Summary

Abstract

The USB/IP project aims to provide users with the ability to access remote USB devices via IP network. 

From a user’s perspective, there is no difference from accessing USB devices those plugged into your 

local machine physically. The project is opened source and could be built into newer Linux kernel by 

proper configuration. The shortage is that there is no official document demonstrating the architecture 

and overall structure of it. This is part of the reason for the coming of this document.

The machine which a USB device physically attached is the server with a Linux system running upon, and the

machine from where a user access USB resource is the client, it can either be a Linux or a Windows box. 

In the following section we will describe the structure of this project, how client talks to server and vice versa.

For simplicity, we will omit case that using a Linux box as the client side machine, and only discuss the topic 

according to the following diagram.

 Windows Client

There are two parts in client side, the user space tool and the underlying virtual bus driver; within this document 

we will refer them to usbip.exe and USBIPEnum.sys, respectively. Firstly, a user launch usbip.exe to query exported

USB devices from a server, and he or she might decide to import a device if there is one available. If the import 

request succeeded, usbip.exe would send an IRP to USBIPEnum.sys informing it to create a physical device object 

which representing a real USB device plugged into the client machine. Certainly, there is no real device attached to

the client machine, but our system will treat it as a real one without aware. The system will then send many IRPs to 

our virtual bus driver for querying purpose, such as device capability querying, device hardware ID querying and so

on. Some queries have nothing to do with the actual device on server side, and our virtual bus driver will finish them

immediately. But when the user access the data store on the remote USB device, our bus driver would receive IRPs 

those associated with URBs (USB request block), the bus driver could not give her back the data required immediately.

In this case, USBIPEnum.sys will look up whether there is a pending read request from usbip.exe, and if 

(1):

There is indeed one pending read request; USBIPEnum.sys will feed the read quest with a URB properly, the IRP is

enqueued and set to pending state. Till this time, the read operation from usbip.exe will successfully returned, 

usbip.exe will then imbed the URB in a package according to the protocol between client and server and send this 

package to the server. Usbip.exe always waits on a socket, when it receives a package from the server, it will call 

WriteFile() API to write the package to our virtual USB device. Upon receiving the write IRP, USBIPEnum.sys gets

data from this write IRP and feeds the former pending IRP with appropriate data, and then that pending IRP would

be completed successfully, it would be de-queued subsequently.  

(2): 

There is no pending read request; the IRP will be enqueued and set to pending state. If there comes 

a read request from usbip.exe some times later, USBIPEnum.sys will search through the queue to get 

an IRP which has not been sent to the server. When it finds one, it will feed the read operation with info

 from that found IRP, and all subsequent behaviors will be exactly the same as (1) above.

Similar to the client side, there are also two parts in server side, the user space tool usbipd and the driver part. Here

we will omit the discussion of usbip tool which used to list USB devices in the system or bind the USB device to our

driver. Usbipd is a tool to meet the requirement from the client side, for example exported devices querying and import

requesting.After usbipd exported a device to a client, a TCP connection would be established between them. Usbipd 

will then send this TCP connection information to the underlying usbiphost driver, the latter will then start two threads 

for receiving and sending purposes, respectively. The receiving thread will then wait on the established TCP connection

port to get request from client side. When the receiving thread gets a submit command from the client, it extract info 

from the package and allocate an URB, set info into this URB appropriately and submit it to the USBCore. When the 

system finish handling this URB, the sending thread in usbip-

host driver will be awaked, it will package the result of this URB and send to the client. There is also another driver named 

usbip-core, which maintains an event handler loop. The event handler loop is started by usbip-host driver by invoking a

method exported by usbip-core. Before starting the event handler, usbip-host driver set some procedures for usbip

core for calling back purpose. For example, when a shutdown event happens, usbip-host will set the event bit, and usbip-

core will be noticed latterly, it then invokes the shutdown event handler which defined in usbip-host driver. 

Client: VMWare+Windbg

Windbg runs on your host machine, it connects to Windows client (XP, Win7) runs on virtual machine via named pipe. 

System that runs on virtual machine imports USB device from remote Linux server.

Server: VMWare+KGDB 

Both systems can run on a virtual machine, one is a debugger that run GDB and the other is a debug gee which act as

a server.Your physical USB device attached to the latter one. The debug gee must be built with kernel debugging switch 

enabled and some other switch enabled if needed. One might encounter some configuration problems while playing with 

this stuff, and there are many web sites you could go for help.

The developer should be familiar with these concepts: Windows Driver Model, IRP, URB, Pending state, etc.