CN100512271C - Distributed device reorienting system and method in terminal network environment - Google Patents

Abstract

The present invention provides a distributed device redirection system in a terminal network environment, including a virtual driver module, a service agent module and a terminal agent module, through application→virtual driver module→service agent module→terminal agent module→terminal device driver→terminal The channel of the device reflects the access logic of the application to the device to the terminal device, and returns according to the inverse of the original channel. In this communication process, the virtual driver often does not care about the details of the operation, but only transmits the device access logic to the terminal device through the network and returns the same way. Using the above-mentioned communication description process can shield the differences in access details of different devices, which has strong versatility; at the same time, by providing specific interfaces, it can provide support for some special-needed device operations, which has strong scalability.

Description

Distributed device redirection system and method thereof in terminal network environment

technical field

The invention relates to a terminal device remote access technology in a graphics terminal application protocol, and more specifically, the invention relates to a distributed device redirection method in a terminal network environment.

Background technique

With the rapid development of network infrastructure and Internet, the use of terminal equipment distributed in the network is becoming more and more popular. Using a network terminal to access various applications on the network has become an important way for people to obtain information and various network services. Many network terminal applications not only involve user interface operations, but also need to operate multiple devices at the same time.

In the graphic terminal application, the application logic is implemented on the application server, and the terminal executes the application program on the server through the network. The target of application program access is the device on the server, and end users often hope that the application can interact with the local device on the terminal. For example, the user terminal logs in to the server and opens an mp3 player to play audio. The user's purpose is obviously to hope that the audio content can be played back on the terminal sound card instead of the server's sound card. The application server's device access to multiple user terminals is a complex and critical issue.

In the desktop environment, the application's access to the device mainly includes the following processes: device opening, initialization, read and write operations, and closing. In this process, the driver must first complete the registration on the operating system, and at the same time provide a file operation interface, and define device operation functions in the interface to meet and correspond to the above-mentioned device operation and control. Applications run in user space, and device drivers run in kernel space. The application's access to the device is completed in the frequent data flow between the user space and the kernel space. In the terminal network environment, the user's operation on the application is realized through the information interaction between the application server and the terminal, and the user's operation target is the terminal's local device. Although the graphical user interface is displayed locally on the terminal, the application logic occurs on the server, and the default application's access to the server device cannot meet the needs of the end user. Therefore, in order to meet the device resource access requirements of multiple end users, it is necessary to convert the application's access to the server device into an access to the terminal local device through the network. The access to the device must satisfy user transparency. The user interface of the user's access to the application on the server is displayed locally, and at the same time, the local device is accessed through the application to realize the device redirection function. In addition, this access mechanism needs to be transparent to the application. The default implementation of the application is to access the server device, and this access logic needs to be reflected on the terminal local device.

Contents of the invention

The purpose of the present invention is to provide a feasible device redirection method with high expansibility and versatility for terminal applications to access devices in a network terminal environment.

An object of the present invention is to meet the multi-user requirements of the network terminal environment, and the device access logic of the application should be redirected to the terminal device of the user who starts the application.

Another object of the present invention is that the device redirection method should be universal and meet the general interface requirements for device access, that is, meet the universality requirements.

Another object of the present invention is to provide special support for the unique access logic of a specific device, and support multiple sub-devices of the same type of device, that is, to meet the scalability requirement.

Another object of the present invention is that the device redirection method requires the support of the server-side universal device virtual driver, and the virtual driver and the server's local standard device driver meet compatibility requirements.

In order to achieve the purpose of the above invention, the present invention provides a distributed device redirection system in a terminal network environment, including a virtual driver module, a service agent module and a terminal agent module, through the virtual driver module, service agent module, terminal The proxy module, the channel from the terminal device driver to the terminal device, reflects the access logic of the application to the device on the terminal device, and returns it in reverse according to the channel, wherein:

The virtual driver module supports registration/logout, listening port and device file operation interface, and realizes data communication with the service agent module based on the redirection protocol;

The service proxy module is used to realize multi-user login support, monitor the status of logged-in users, and determine the user who starts the application; realize the communication interface and protocol description between the service proxy module and the virtual driver module, and the service proxy module and the terminal proxy module;

The terminal agent module sends the user login request, realizes the communication interface and protocol description with the service agent module, analyzes the device access logic and then operates the terminal local device.

In order to achieve the purpose of the above invention, the present invention provides a distributed device redirection method in a terminal network environment, including the following steps:

Load the virtual driver;

Start the service agent and establish a connection with the virtual driver;

User remote login;

The user starts the application in the terminal application environment;

application access device;

The device access logic is passed to the service agent through the virtual driver;

The device access logic is passed to the terminal agent through the service agent;

The terminal proxy parses the access logic and implements local device access;

It can be seen from the above that what the present invention implements on the server is a lightweight virtual driver. Compared with the standard driver, the registration/deregistration and operation interface of the device files of the two are consistent, but the actual device operation is not executed, but the operation logic of the application is transmitted to the terminal through the network, and the feedback is returned to the server on the server. application. In this communication process, the virtual driver often does not care about the details of the operation, but only transmits the device access logic to the terminal device through the network and returns the same way. Using the above-mentioned communication description process can shield the differences in access details of different devices, which has strong versatility; at the same time, by providing specific interfaces, it can provide support for some special-needed device operations, which has strong scalability.

Description of drawings

Fig. 1 is a schematic structural diagram of the device redirection system of the present invention;

Fig. 2 is a flow chart of establishing the relationship between the application process identification pid and the user session identification sid of the present invention;

Fig. 3 is a method flowchart of the present invention;

Fig. 4 is the flowchart of the virtual drive of the present invention;

Fig. 5 is a schematic diagram of protocol interaction in the present invention.

Detailed ways

The technical solution of the present invention will be described in detail below with reference to the accompanying drawings.

As shown in Figure 1, in order to achieve the purpose of the above invention, the present invention provides a distributed device redirection system in a graphic terminal environment, which mainly includes a virtual driver module, a service agent module and a terminal agent module, through "application→virtual driver module →Service proxy module→Terminal proxy module→Terminal device driver→Terminal device" channel, which reflects the access logic of the application to the device on the terminal device, and returns according to the reverse of the original channel, realizes device redirection, and satisfies the needs of multi-user terminal networks The device support needs in the environment.

More specifically, the device redirection system includes a virtual driver module, which supports registration/logout, listening port and device file operation interface, and realizes data communication with the service agent module based on the redirection protocol. Among them, the virtual driver module includes:

Register the interface unit, and the registered primary and secondary device numbers are consistent with the device numbers of the system standard equipment. According to the actual equipment needs, register multiple secondary devices to meet the scalability requirements. The registration interface provides multi-thread support in kernel space, and provides port monitoring function in the new thread.

The port monitoring unit establishes a redirection channel from the virtual driver to the service agent, and completes the establishment and monitoring of the communication port. The virtual driver receives the login session identifier sid sent by the service agent, and records the correspondence between the sid and the communication port.

The device file operation interface unit supports standard device access interfaces according to the process of device opening, device I/O control, device reading and writing, and device closing. The interface definition conforms to the standard-driven design principles and meets the compatibility requirements with standard equipment.

The device opens the interface unit, completes the conversion of the application process identifier pid and the session identifier sid with the service agent, and determines the user session that starts the application according to the result. Send the opening logic description to the service agent and receive feedback from the service agent.

The device I/O control interface unit sends the I/O control logic description to the service agent and receives feedback from the service agent.

The device read interface unit sends the read logic description to the service agent, and receives feedback from the service agent, the feedback includes the device information acquired by the read device.

The device write interface unit sends the write logic description to the service agent, the description includes the data written to the device, and receives the feedback from the service agent.

The device shuts down the interface unit, sends the shutdown logic description to the service agent, and receives feedback from the service agent.

The device redirection system also includes a service agent module, which is used to realize multi-user login support, monitor the status of logged-in users, and determine the user who starts the application; realize the communication interface between the service agent module and the virtual driver module, and the service agent module and the terminal agent module. protocol description. Among them, the service proxy module includes:

The multi-thread management unit monitors and manages the session environment of multiple terminal users logging in. A shared memory unit that records user session IDs.

The "service agent module-virtual driver module" communication interface unit interacts with user session identifiers and application process identifiers, builds a device redirection channel between the service agent module and the virtual driver module, and transparently realizes the transmission of device access logic between the two.

The "service agent module-terminal agent module" communication interface unit builds a device redirection channel between the service agent module and the terminal agent module, and transparently realizes the transmission of device access logic between the two.

The device redirection system also includes a terminal agent module, which sends user login requests, realizes the communication interface and protocol description with the service agent module, analyzes the device access logic, and then operates the terminal local device. Among them, the terminal agent module includes:

The "terminal proxy module-service proxy module" communication interface unit sends a login request and builds a device redirection channel between the terminal proxy module and the service proxy module.

The access logic analysis unit analyzes different access logic descriptions.

The device access unit accesses the local device of the terminal according to the analysis result, completes the device opening, I/O control, device read and write and close operations performed by the application program initiated by the end user, and returns the device access feedback to the service agent.

In the following, the function description of the embodiment of the present invention will be described first with reference to the accompanying drawings, and then the information interaction process of device redirection will be described in detail in combination with a development example of audio device redirection.

Design and implementation of virtual drive module:

In the graphic terminal application, the virtual driver on the application server runs through the kernel or module mode, and monitors the request from the terminal service agent. If the user does not run the audio application, the communication status between the virtual driver and the terminal service agent remains unchanged; if the user runs the audio application on the server, the access logic is executed according to the description of the application.

The implementation of registration/deregistration of the virtual driver follows the standard driver design. The interface is init_module() and cleanup_module(). The registered primary and secondary device numbers are consistent with the device numbers of the system standard devices. It is completed through the devfs_register_dev() and devfs_mk_dir() functions, satisfying Server-side device description conformance requirements.

The virtual driver of the present invention starts the monitoring thread through kernel_thread(), and monitors the communication port with the service agent. The monitoring process is shown in the figure. The listening thread waits for a connection request from the service agent in order to obtain session information for login or logout. The request format of the service proxy is "session description + session ID". Login and logout sessions are denoted by "CN" and "DS", respectively. The virtual driver obtains the session identifier sid, and records the corresponding relationship between the sid and the communication port in the system list for the login session for later use; for the logout session, deletes it and the corresponding communication port information from the list.

The operation of the application on the device is performed in the order of device opening, device I/O control, device reading and writing, and device closing. The operation of the application on the device is implemented in the driver through the definition of the device file operation interface file_operations structure. The virtual driver mainly reflects the access logic of the application to the device on the terminal device through the channel of "application→virtual driver→service agent→terminal agent→terminal device driver→terminal device", and returns according to the reverse of the original channel. It is worth noting that each type of access logic contains opcodes and operands, which describe the operation command and operation object respectively. The above-mentioned communication process is transparent, and this transparency is always maintained throughout the above-mentioned communication process, and the intermediate virtual driver and each agent do not care about the details of the command. Analysis is performed at the end of the terminal agent. The terminal agent parses the operation code and operand, and completes the I/O control operation of the real device through the standard call interface according to the result.

The invention obtains the process identifier pid of the audio application through the virtual driver registered in the kernel to open the device interface, and transmits the pid to the service agent through the data communication between the virtual driver and the terminal service agent, and obtains the start of the audio application on the agent The user session identifies sid and returns the driver. A legal sid return indicates that the audio application is executed by a legitimate terminal login user. Search the comparison list between the sid and the communication port to obtain the communication port with the corresponding session. At this time, the corresponding relationship between the user and the application is established to serve different session processes in the future. Separation of data. The process is shown in Figure 2. At the same time, normal open information is returned to the application.

After the application opens the device, it needs to operate through the device I/O control interface ioctl to set, obtain and modify the I/O properties of the device. I/O control is a relatively complex operation in the device driver, and the interface definition includes command words (opcodes) and parameters (operands). In the present invention, when the device I/O control operation is applied, the virtual driver only obtains the control command word used by the application program from the system call interface and analyzes it. The operation type obtained by macro definition _IOC_DIR() for the operation code is NONE, OUT , IN or INOUT type commands, respectively corresponding to four types without parameters, setting parameters, reading parameters, and negotiating parameters, and then calling the corresponding processing procedures respectively, using the protocol interaction part to complete its functions, and applying the I/O to the device O controls redirection to the end device.

In device operations, read and write operations are the most frequently occurring operations, and are generally in the loop logic of the application program. Read and write operations have two notable features: one is that the operand part is huge, and the buffer pointer is often passed; the other is that the read and write status needs to be returned, and there are many factors that affect the returned status. When the present invention designs the communication protocol of read and write operations, the buffer part of the operation data often adopts an indefinite length mode, and a length byte is used to describe the size of the actual buffer. The return status is entirely dependent on the feedback of the actual operation of the end device.

The device closing operation of the present invention is transparently transmitted to the service agent through the redirection protocol defined between the virtual driver module and the service agent module.

Design and implementation of the service proxy module:

In the present invention, the service agent module mainly includes information sending and receiving interfaces. The information sending interface realizes receiving various requests from the virtual driver, and repackages them into services—the protocol format between terminal agents (mainly different byte order), and forwards the requests to the client agent; the information receiving interface receives from the client agent Various responses are repackaged into the protocol format (mainly different byte order) between the service agent and the virtual driver, and sent to the virtual driver.

Design and Implementation of Terminal Agent Module

In the present invention, the proxy part of the client side provides the protocol interaction part corresponding to the sending and receiving of the service proxy module. In addition, it is necessary to design and realize the access to the local device according to the access logic description notified by the service agent. The access to the local device adopts the standard device operation interface, and the feedback of the operation result needs to be returned to the terminal service agent.

4. Design and implementation of communication protocol, that is, design and implementation of redirection protocol:

It includes three parts: device discovery, device description and device access.

Device discovery mainly realizes the discovery, notification and feedback of the existing devices of the terminal. Some devices already exist and take effect when the terminal is powered on, such as keyboard/mouse, three cards (graphics card, network card and sound card) and so on. These devices will notify the service agent and record on the server side when the user logs in to the terminal service; and some devices support plug and play functions, as is the case with USB devices. A device such as this may connect to the terminal and notify Terminal Services before or after the user logs on. In either case, the protocol needs to describe the device discovery message to the terminal service, and return the feedback description of the terminal service to the terminal agent.

Device description. Once a device is discovered, the terminal needs to be able to provide specific description information of the device to the server. The description information should at least include device type, device descriptor, and device capability description.

Terminal devices are roughly divided into two categories: character devices and block devices. I/O for character devices is measured in bytes, while I/O for block devices is measured in blocks of records, or "sectors". Through decades of development, the line between block devices and character devices has blurred, but this division is still used.

The device descriptor is mainly used to distinguish specific devices on the terminal, and the terminal device descriptor can be used directly, such as dsp, mixer, etc. for audio devices, hda, sda, etc. for disk devices; it can also be described by primary and secondary device numbers, primary and secondary The allocation of device numbers is described according to the major and minor device numbers of the terminal operating system. For example, the major and minor device numbers of the dsp and mixer of the audio device are 14/3 and 14/0 respectively.

The device capability description is the auxiliary information related to the device, which depends on the specific device and describes the current I/O capability and usage status of the device. The device capability description is also to serve the needs of terminal device adaptive capability support in the future.

Device access, the implementation of this part is mainly introduced in the invention application, describing the opening, I/O control, reading and writing and closing logic of the device.

In the present invention, the communication protocol between the agent modules includes two parts: service-to-terminal request and terminal-to-service response. They are described as follows:

1) The request packet format is shown in Table 1:

Table 1 Data packet format from virtual driver to terminal

length operation code parameter field table 2 bytes 1 byte variable length

The fields are defined as follows:

Length field: the length of the entire packet.

There is no poll item in the definition of the operation in the operations structure. The poll operation is used for select calls in the system, and is specially used to deal with the contradiction between high-speed CPU and low-speed peripheral operations. The essence of the Select system call is to change the sleep waiting of a single process in the system into a multi-object sleep waiting to improve the operating efficiency of the entire system. If the terminal service process calls the select system call, what is actually waiting should be the operation returned from the remote terminal, which depends on two factors: the read waiting process on the terminal and the terminal transmitting the read result to the virtual driver through the network. Therefore, the poll call should actually correspond to the socket call that provides data transmission between the virtual driver and the terminal. Therefore, in Table 2, there is no need to specify the operation code for transmitting the poll operation to the terminal, and it is only necessary to directly call the poll process of the corresponding socket for the poll operation.

Parameter field: specifies the parameter format of the corresponding operation code, and the specific format is shown in Table 3. The parameter type specifies the format of the data in this parameter, such as 16-bit integer, 32-bit integer, byte stream, etc. Only when the parameter data type is a byte stream, there is a parameter length field in the parameter structure. The subsequent parameter value field is the actual parameter value.

Table 3 parameter format

Parameter Type parameter length parameter value 1 byte 2 bytes variable length

2) The response packet format is shown in Table 4:

Table 4 Terminal device operation response

success mark length parameter field table 1 byte 2 bytes variable length

The meaning of each field is as follows:

Success flag: Indicates the execution result of the access request initiated by the application on the actual device of the terminal. A value of 1 means that the execution is successful, otherwise it means that an error occurred during the execution.

Length field: indicates the total length of the following data.

Parameter field: the specific format is shown in the table. Return value or optional parameter for this operation.

As shown in Figure 3, the redirection method of the present invention includes the following steps:

Step 100, loading a virtual driver;

Step 110, start the service agent, and establish a connection with the virtual driver;

Step 120, the user logs in remotely (at this time, by the service agent, the relationship between the session identification sid and the communication port is recorded in the virtual driver);

Step 130, the user starts the application in the terminal application environment;

Step 140, the application sends a device access request to the virtual driver to form device access logic;

Step 150, the device access logic is transmitted to the service agent through the virtual driver;

Step 150, the device access logic is transmitted to the service agent through the virtual driver;

Step 160, the device access logic is transmitted to the terminal agent through the service agent;

Step 170, the terminal proxy parses the access logic and implements local device access;

The feedback of device access is returned by the above route;

As shown in Figure 4, the implementation process of the virtual drive includes the following steps:

Step 200, application system call;

Step 210, judge the type of system call, if the system call is an open call, then perform the next step, if the system call is an ioctl call, then perform step 230, if it is other calls, then perform step 240; wherein, the system call includes an open call , release call, read call, write call, ioctl call, poll call.

Step 220, obtain port information communicating with the corresponding session, and execute step 240;

Step 230, judge the type of ioctl, and perform corresponding processing, and execute step 240;

Step 240, protocol interaction;

Step 250, the call returns.

In step 240, as shown in FIG. 5, 1-3 is the access logic mapping, and 4-6 is the access feedback.

In the graphic terminal environment, multimedia application is an important application. In order to satisfy the support for audio applications, better support for audio devices in the terminal network is the focus of the device redirection studied in the present invention.

In combination with the description of the implementation process of the above invention, the specific implementation process of the device redirection in the present invention is described by taking audio device redirection as an implementation example. With the development of sound device hardware and the enrichment of applications, audio applications require sound cards to support MIDI devices, mixer devices, and the like. Among them, the mixer device /dev/mixer is widely used as a volume adjustment tool in most audio applications. The invention has good expansibility and can support various device descriptions. The implementation principle of the mixer is exactly the same as that of the traditional audio equipment, and the following mainly introduces the implementation examples for the traditional audio equipment /dev/dsp.

1) User login and registration

The virtual driver is first loaded into the kernel as a module, and the registration process in the kernel is as described above. After the registration is complete, the port monitoring thread is started, and the information from the service agent is monitored (the service agent has not been started at this time). Start the service agent and listen for messages from the terminal agent. The terminal agent initiates a user login request and establishes a connection with the service agent. For each newly logged-in user, the service agent assigns the user session identifier sid, and starts a thread to maintain connection and data communication with the user. Pass the user's sid to the virtual driver through the request information in the thread. The virtual driver receives the sid from the service agent, records the relationship information between the sid and the communication port, and completes the user login and registration process.

2) Application startup process

End users start audio applications on the service through a graphical interface. The audio application first operates the audio device file descriptor /dev/dsp through the open command to open the audio device, and this operation information is passed to the device file opening interface dev_open of the virtual driver through the kernel. In this interface, according to the above process, the obtained application process identifier pid is passed to the service agent. The service agent obtains the pid, obtains the session identifier sid by accessing the /proc file system, and sends it back to the virtual driver. The virtual driver obtains the communication port of the session communication corresponding to the audio application process through the relationship between the recorded sid and the communication port.

3) Application access to the sound card

The I/O control of the sound card is relatively rich, and a lot of information about the properties of the sound card device can be set and obtained. Taking the buffer information as an example, the sound card can set and obtain the size of the buffer, which correspond to the above OUT and IN commands respectively. The interface definition of sound card buffer settings in the application is:

ioctl(int audio_fd, int cmd, char*blocksize)

Among them, audio_fd is the file number of the sound card device, cmd is the command word, here it is SNDCTL_DSP_GETBLKSIZE, indicating that the command needs to obtain the buffer size, and blocksize is the returned buffer size. This command is mapped to the virtual driver, and the operation interface in the virtual driver is

dev_ioctl(struct inode*inode, struct file*file, unsigned int cmd, unsigned long arg)

Among them, cmd corresponds to the command word, and arg corresponds to the parameter. The virtual driver needs to parse the type of the command word through _IOC_DIR (cmd), and transparently pass the combination of the command word and parameters to the service agent according to the type.

Setting buffer sizes and other I/O controls is the same as above.

The main operation on the sound card device is to read and write the sound card. The application's reading and writing to the sound card corresponds to the audio recording and playback functions. The following is an example of an audio application write buffer interface. The audio application write buffer interface is:

write(int audio_fd, const void*buffer, size_t count)

Among them, audio_fd is the file number of the sound card device, buffer is the buffer pointer for storing audio data, and count represents the size of the buffer in bytes. This command is mapped to the virtual driver, and the operation interface in the virtual driver is

dev_write(struct file*file, const char*buffer, size_t count, loff_t*ppos)

Among them, buffer is a pointer to the buffer receiving user-space audio data, and count is the size of the buffer. The writing logic of the audio application to the sound card is reflected to the virtual driver, and then transparently passed to the service agent.

The read logic for audio applications is similar to the write logic mapping process, but the data flow direction is reversed.

4) Turn off the sound card

The device close of the audio application is passed to the service agent through the virtual driver.

5) Logout of the virtual device driver

Once a virtual driver is loaded, it is generally not unregistered from the kernel. In order to meet the consistency with the standard device driver, the virtual driver provides a device unregister interface, which is implemented through devfs_unregister_chrdev() and devfs_unregister().

What has been introduced above is the implementation example of the core of the present invention—virtual device driver. Service agent, terminal agent and virtual device driver together constitute the communication channel for device redirection, and the key to implementation is the definition of communication protocol. The following takes audio data writing, which occurs most frequently in audio applications, as an example to introduce the communication protocol between the service and the terminal agent.

After receiving the write operation command of the virtual driver, the service agent organizes the data packets according to the device redirection protocol defined between the agents and sends them to the terminal agent. For example, if the size of the sound data written in each write operation is 4096 bytes, the construction data package is as follows:

length operation code Parameter Type parameter length parameter value 4100 3 B 4096 audio data

The length field is 4100 (1+1+2+4096), indicating that the total length of the sent data (excluding the length field) is 4100 bytes; the operation code is 3, indicating that this operation is a write operation; the parameter type is "B", indicating that the follow-up The data is a byte stream; the parameter length is 4096, indicating that the parameter value field length is 4096 bytes; the parameter value part is stored by the audio application and needs to be written to the audio data in the sound card.

Since the sound card write operation only needs to feedback whether it is successful or not, the return message is simple and only describes whether it is successful or not. If it is an IN command for sound card reading or I/O operation, such as reading 4096 bytes of data at a time, the return message is as follows:

success mark length Parameter Type parameter length parameter value 1 4099 B 4096 audio data

The success mark field is 1, indicating that the return is valid; the length field is 4099, indicating that the total length of subsequent data is 4099 bytes; the parameter type field is "B", indicating that the subsequent data is a byte stream; the parameter length field is 4096, indicating that the parameters The value length is 4096 bytes; the parameter value part is audio data.

The device redirection method of the present invention is simple to realize and has strong versatility. What is implemented on the server is a lightweight virtual driver. Compared with the standard driver, the registration/deregistration and operation interface of the device files of the two are consistent, but the actual device operation is not executed, but the operation logic of the application is transmitted to the terminal through the network, and the feedback is returned to the server on the server. application. In this communication process, the virtual driver often does not care about the details of the operation, but only transmits the device access logic to the terminal device through the network and returns the same way. Using the above-mentioned communication description process can shield the differences in access details of different devices, which has strong versatility; at the same time, by providing specific interfaces, it can provide support for some special-needed device operations, and has strong scalability; the above-mentioned communication method The logic is clear, and the network communication between the service agent and the terminal agent adopts a subset of the intelligent network application protocol, that is, the device redirection protocol.

Finally, it should be noted that: the above embodiments are only used to illustrate and not limit the technical solutions of the present invention, although the present invention has been described in detail with reference to the above embodiments, those of ordinary skill in the art should understand that: the present invention can still be modified or Any modification or partial replacement without departing from the spirit and scope of the present invention shall fall within the scope of the claims of the present invention.

Claims (9)

1, the distributed apparatus Redirectional system in a kind of terminal network environment, it is characterized in that, comprise virtual drive module, service agent module and terminal proxy module, by using the passage of process virtual drive module, service agent module, terminal proxy module, terminal equipment driving and terminal equipment successively, the access logic of using equipment is reflected on the terminal equipment, and return according to described passage is contrary, wherein:

Virtual drive module is supported registration/cancellation, listening port and device file operation-interface, based on redirected agreement, and the data communication between realization and service agent module;

Service agent module is used to realize that the multi-user lands support, monitors the login user situation, judges to start the user who uses; Realize communication interface and protocol description between service agent module and virtual drive module and service agent module and terminal proxy module;

The terminal proxy module sends the user and lands request, communication interface and protocol description between realization and service agent module, and the analyzing device access logic is the operating terminal local device then.

2, the system as claimed in claim 1, it is characterized in that, virtual drive module comprises the registration interface unit, the port monitoring unit, device file operation-interface unit, equipment is opened interface unit, equipment I/O control interface unit, equipment is read interface unit, and equipment is write interface unit and device shutdown interface unit, wherein:

The registration interface unit is used to register primary and secondary equipment, and the support of kernel spacing multithreading is provided, and the port monitor function is provided in new thread;

The port monitoring unit is used to set up the redirected passage of virtual drive module to service agent module;

Device file operation-interface unit, be used for according to equipment open, the process of the control of equipment I/O, equipment read-write and device shutdown supports the standard device access interface;

Equipment is opened interface unit, be used for finishing the conversion of application process sign pid and session identification sid with service agent module, judge the user conversation of start using according to the result, and will open logical description and send to service agent module, and accept feedback from service agent module;

Equipment I/O control interface unit is used for the description of I/O control logic is sent to service agent module, and accepts the feedback from service agent module;

Equipment is read interface unit, be used for sending to service agent module with reading logical description, and acceptance is from the feedback of service agent module;

Equipment is write interface unit, will write logical description and send to service agent module, describes to comprise the data of writing to equipment, and accepts the feedback of service agent module;

The device shutdown interface unit is used for sending to service agent module with closing logical description, and accepts the feedback from service agent module.

3, system as claimed in claim 2 is characterized in that, the primary and secondary device number of described registration interface unit (ONU) registration is consistent with the device number of system standard equipment.

4, the system as claimed in claim 1, it is characterized in that, described service agent module comprises multiple line distance management unit and shared drive unit, communications interface unit between described service agent module and the virtual drive module, and service agent module is to the communications interface unit between the terminal proxy module, wherein:

The multiple line distance management unit is used to monitor and manage the session-context that a plurality of terminal uses land;

The shared drive unit is used for the recording user session identification;

Communications interface unit between service agent module and the virtual drive module is used for interactive user session identification and application process sign, makes up the device redirection passage between service agent module and virtual drive module, realizes the transmission of device access logic between the two;

Service agent module is used to make up the device redirection passage between service agent module and terminal proxy module to the communications interface unit of terminal proxy module, realizes the transmission of device access logic between the two.

5, the system as claimed in claim 1 is characterized in that, described terminal proxy module comprises terminal proxy module-service agent module communications interface unit, access logic resolution unit and device access unit, wherein:

Terminal proxy module-service agent module communications interface unit is used for sending the request of landing, and makes up the device redirection passage between terminal proxy module and service agent module;

The access logic resolution unit is used to analyze different access logics and describes;

The device access unit is used for according to analysis result access terminal local device, and the equipment of finishing the execution of terminal use's application program started is opened, I/O controls, equipment is read and write and shutoff operation, and the feedback of device access is returned service agent module.

6, the system as claimed in claim 1 is characterized in that, redirected agreement comprises device discovery, device description and device access, and wherein: device discovery is used to realize discovery, notice and the feedback to the terminal existing equipment; Device descriptor mainly is the concrete equipment that is used on the distinguishing terminal; Device access is used to the opening of the equipment of describing, I/O control, reads and writes and close logic.

7, the distributed apparatus reorientation method in a kind of terminal network environment may further comprise the steps:

A) load virtual driving;

B) start the service broker, foundation is connected with virtual driving;

C) user's telnet;

D) user starts application in the terminal applies environment;

E) application is sent the device access request to virtual driving, the forming device access logic;

F) the device access logic is passed to the service broker by virtual driving;

G) the device access logic is passed to the terminal agency by the service broker;

H) terminal proxy resolution access logic, and realize the local device visit.

8, method as claimed in claim 7 is characterized in that, in the step c), and by the service broker, the relation in virtual driving between recording conversation sign sid and communication port.

9, method as claimed in claim 7 is characterized in that, virtual driving realizes may further comprise the steps:

A1). receive system call from application system;

B1). judge the kind of system call, call if system call is open, then carry out next step, call if system call is ioctl, then execution in step d1), if for other calls, execution in step e1 then);

C1). obtain the port information with corresponding session communication, execution in step e1);

D1). judge the ioctl type, and handle accordingly execution in step e1);

E1). protocol interaction;

F1). call and return.

Images