1. Field of the Invention
Embodiments of the present invention relate generally to computing systems and, more specifically, to a method for providing shared access to a remotely running application.
2. Description of the Related Art
Currently, in software development and other information-based disciplines collaborative projects are hindered not by distances between the different individuals participating in the collaborative work, but by the inability of the collaborating individuals to work together in “real-time” on the same software application or other software product. While an individual contributor can work with and/or modify an application in series with many other contributors, it is difficult to coordinate the different changes. Furthermore, each collaborator has limited visibility with respect to what actions are being made in real-time to the target. Accordingly, there is a need in the art for methods and systems that allow multiple users to have simultaneous, shared control of an application and access to the output of the application.
One or more embodiments of the present invention set forth a computer-implemented method for shared control by two or more users of a program running on a computing system, even when the users control the program from computing systems that are separated by a network firewall. A hoster application engages the application program via a pseudo terminal in a hoster computing system and also requests a connection to a conductor application. The conductor application is accessible to both the hoster application and to one or more actor applications, where each actor application is configured to provide a remote user control of the application program by transmitting data to the hoster application via the conductor application.
In accordance with an embodiment, a non-transitory computer-readable medium including instructions that, when executed by a processing unit, cause the processing unit to perform the steps of: monitoring a known port for connection requests; receiving a request from a first application for connection via an open port; in response to the receiving, establishing an actor port for connection with a second application; transmitting data received via the actor port from the second application to the first application via the known port; and transmitting data received via the known port from the first application to the second application via the actor port, wherein the first application provides the data received via the actor port to a third application via a pseudo terminal.
In accordance with another embodiment, a non-transitory computer-readable medium including instructions that, when executed by a processing unit, cause the processing unit to perform the steps of: requesting a connection with a first application via a port; engaging a second application that is run on the processing unit; writing data received via the connection to the second application; and transmitting output data from the second application to the first application via the connection, wherein the data received via the connection comprise data from a third application.
In accordance with a further embodiment, a computing device comprising: a processing unit; and a memory coupled to the processing unit and including instructions that, when executed by the processing unit, cause the processing unit to perform the steps of: requesting a connection with a first application via a port; engaging a second application that is run on the processing unit; writing data received via the connection to the second application; and transmitting output data from the second application to the first application via the connection, wherein the data received via the connection comprise data from a third application.
So that the manner in which the above recited features of the present invention can be understood in detail, a more particular description of the invention, briefly summarized above, may be had by reference to embodiments, some of which are illustrated in the appended drawings. It is to be noted, however, that the appended drawings illustrate only typical embodiments of this invention and are therefore not to be considered limiting of its scope, for the invention may admit to other equally effective embodiments.
For clarity, identical reference numbers have been used, where applicable, to designate identical elements that are common between figures. It is contemplated that features of one embodiment may be incorporated in other embodiments without further recitation.
Hoster application 120 is an application configured to run on a hoster device 121, to engage a separate application program 122 that also runs on hoster device 121, to provide input data 124 to application program 122, and to transmit output data 125 from application program 122. Hoster application 120 engages application program 122 via a pseudo terminal 126, consequently hoster application 120 provides input data 124 to application program 122 via pseudo terminal 126 and receives output data 125 from application program 122 via pseudo terminal 126.
Hoster application 120 is further configured, upon being started, to request a connection 129 with conductor application 130 via a known port 133. Once connection 129 is established, hoster application 120 transmits output data 125 to conductor application 130 and receives input data 124 from conductor 130 via connection 129. In some embodiments, hoster application 120 is configured to provide authentication to conductor application 130 as part of the request for connection 129. Authentication may include a user name and/or password, or other authorization credential transmitted to conductor application 130 using any technically feasible secure password authentication protocol. In some embodiments, said authentication protocol may be based on the authorization credential being obtained by conductor application 130 prior to the connection request. In other embodiments, an authentication protocol can include a user of hoster device 121 authenticating through a social networking account, such as Facebook®, or an on-line data management account, such as a Google® Account. Once the desired authentication protocol is successfully performed, input data 124 and output data 125 are transmitted between hoster application 120 and conductor application 130.
Input data 124 can have at least two origins: (1) data that are input into hoster application 120 by a user via a hoster terminal 123, or (2) data that originate from one or more actor applications 140, received by conductor application 130, and directed to hoster application 120 (actor application 140 and conductor application 130 are described in greater detail below). In either case, hoster application 120 provides said input data 124 to application program 122 via pseudo terminal 126. Thus, data entered by a remote user via actor application 140 can be used to control application program 122.
Output data 125, which includes data sent to pseudo terminal 126 from application program 122, are received from application program 122 by hoster application 120 (via pseudo terminal 126). Hoster application 120 then directs output data 125 to hoster terminal 123 for display to a user and also to conductor application 130 for further transmission to one or more actor applications 140. Alternatively, hoster application 120 may transmit the output to conductor application 130 repeatedly for each actor application 140 connected. In this way, data output by application program 122 can be displayed to one or more remote users via actor application 140. It is noted that because output data 125 comprise data that are sent to pseudo terminal 126, input data 124 sent to pseudo terminal 126 are typically “echoed back” to hoster application 120 as output data 125 and are then sent to hoster terminal 123 and conductor application 130 for display to users as described above. Note that applications do not always “echoed back” input data 124 from pseudo terminal 126 as output data 125. One example is when input data 124 includes a password entered by a user of application program 122.
In some embodiments, input data 124 and output data 125 comprise character data, which is particularly useful when application program 122 is configured as a command interpreter, such as the well-known “shell” of UNIX/LINUX/Mac or the Windows “Command Prompt.” In other applications, input data 124 and output data 125 comprise other data forms, such as binary data, graphical data, and the like. It is noted that in some embodiments, input data 124 and output data 125 can be transmitted as individual bytes of data. Such embodiments are of particular importance when application program 122 comprises a command-line program, since each character or byte received by such a program can be individually interpreted by the program and by the users sharing control thereof.
In some embodiments, hoster application 120 comprises a first thread of execution that handles the transfer of input data 124 from conductor application 130 to pseudo terminal 126, and a second thread of execution that handles the transfer of output data 125 from pseudo terminal 126 to conductor application 130 and to hoster terminal 123.
Application program 122 includes a program configured to run on hoster device 121 and to be connected to a terminal. In some embodiments, application program 122 includes a command interpreter, such as a UNIX/LINUX/Mac shell or a Windows command. Examples of such programs are manifold, including backup programs, test programs, inventory programs, contact list management programs, programs used for maintenance or diagnosing computer problems, etc. In such embodiments, input data 124, whether they are input by a user via hoster terminal 123 or originate from one or more actor applications 140, are interpreted as character inputs when received by application program 122. Similarly, in such embodiments, output data 125 of application program 122 generally comprises character data, which is displayed to users (via hoster application 120) at hoster terminal 123 and at one or more actor devices 141. Alternatively, application program 122 may include a program that is not configured as a command interpreter, and input data 124 and output data 125 may include more than just character data. In such embodiments, hoster application 120 and actor application 140 may include additional functionality that facilitates generation and interpretation of such non-character, application-specific data.
In some embodiments, an operating system 119 (illustrated in
Pseudo terminal 126 provides a bidirectional communication channel between application program 122 and hoster application 120. Pseudo terminal 126 receives input data 124 from hoster application 120 and directs said input data 124 to application program 122. In addition, the input data 124 received by pseudo terminal may be “echoed back” to hoster application 120, essentially as output data 125, which hoster application 120 then directs to hoster terminal 123 for display to a user and to one or more actor applications 140 for display to one or more remote users. Similarly, pseudo terminal 126 receives output data 125 from application program 122 and directs said output data 125 to hoster application 120. Hoster application 120 then directs said output data 125 to hoster terminal 123 for display to a user and to one or more actor applications 140 for display to one or more remote users. Hoster application 120 opens pseudo terminal 126, and then hoster application 120 starts application program 122 with its output available from pseudo terminal 126.
Hoster terminal 123 provides an interface to a user for hoster application 120 and for application program 122. Hoster terminal 123 may comprise a virtual terminal, such as a terminal emulator or terminal window, including, for example, the well-known GNOME-terminal, xterm, and the like. Alternatively, hoster terminal 123 may comprise a physical terminal that is configured to behave like a “dumb” terminal, and does not locally process data or execute user programs. In some embodiments, hoster terminal 123 may comprise a graphical user interface and/or a command-line interface. In some embodiments, hoster terminal may be incorporated inside a browser, such as Internet Explorer®, Firefox®, or Google Chrome®. It is noted that in some embodiments, data entered by a user in hoster terminal 123 is not directly displayed by hoster terminal 123. Instead, hoster terminal 123 displays such entered data only when echoed back from pseudo terminal 126 as output data 125.
Hoster device 121 comprises any computing device suitable for running hoster application 120, application program 122, and pseudo terminal 126, such as a desktop computer, a laptop computer, a smartphone, a digital tablet, a personal digital assistant, a smart grid-enabled appliance, and the like.
Conductor application 130 (shown in
In operation, conductor application 130 is configured to open a pre-determined socket or port, e.g., known port 133, monitor said port for connection requests from hoster application 120, establish another port, e.g., actor port 132, for traffic from one or more actor applications 140, and transfer data between hoster application 120 and the one or more actor applications 140. In some embodiments, known port 133 comprises a secure port to withstand “man-in-the-middle” and eavesdropping attacks, such as port 443, and an authentication protocol with hoster application 120 may be used to authenticate any connection made with hoster application 120 via known port 133. In such embodiments, conductor application 130 resides on a network that has no firewalls protecting it and blocking incoming traffic, thereby facilitating the remote control of application program 122 by one or more actor applications 140 when the actor applications 140 and application program 122 are separated by one or more network firewalls. For example, firewalls typically block incoming traffic to networks such as the network where hoster device 121 resides and actor device 141 reside.
Actor application 140 comprises a user-level application that is loaded on an actor device 141 and enables a remote user to control or observe application program 122. Actor device 141 may comprise a computing device substantially similar in organization and operation to hoster device 121, described above in conjunction with
In operation, actor application 140 typically receives an invitation 160 to join a shared control session of application program 122. In the embodiment illustrated in
As shown, method 300 begins at step 301, where hoster application 120 receives a start command from a user, for example via hoster terminal 123.
In step 302, after startup, hoster application 120 requests connection 129 with conductor application 130 via known port 133. As described above in conjunction with
In step 303, after connection 129 is established, hoster application 120 may receive an ID and other connection information from conductor application 130 to enable one or more actor applications 140 to connect to conductor application 130 via actor port 132. Hoster application 120 may then send invitation 160 to one or more remote users via e-mail, text message, instant message, etc. Alternatively, in some embodiments, conductor application 130 sends invitation 160 directly to the desired one or more remote users and step 303 is not performed. In still other embodiments, the user of hoster device 121 communicates the ID and other connection information to the user of actor device 141 via telephone or other “out-of-band” mechanism. In any case, each of the one or more actor applications 140 so invited may be designated in invitation 160 as a “read/write” actor application, which can share control of application program 122, or as an “observer only” application, which can only observe output from application program 122 and/or input data 124 directed to application program 122.
In step 304, hoster application 120 engages application program 122 with pseudo terminal 126. In some embodiments, hoster application 120 requests that pseudo terminal 126 is opened by operating system 119. In some embodiments, hoster application 120 also requests that operating system 119 start application program 122. In other embodiments, application program 122 may be started by a user of hoster device 121 via pseudo terminal 126. In other embodiments, application program 122 may already be running prior to step 304.
In step 305, hoster application 120 receives output data 125 from pseudo terminal 126. As noted above, output data 125 received by hoster application 120 may include data output by application program 122 or “echoed data,” e.g., input data 124 that have been directed to pseudo terminal 126 from hoster application 120.
In step 306, hoster application 120 directs output data 125 received in step 305 to hoster terminal 123 for display to the user of hoster device 121. Hoster application 120 also transmits said output data 125 to conductor application 130 via connection 129. Conductor application 130 then transmits output data 125 to one or more remotely running actor applications 140.
In step 307, which may occur concurrently with steps 305 and 306, hoster application 120 receives input data 124, either from hoster terminal 123 or from conductor application 130 via connection 129. In some embodiments, hoster application 120 “pulls” input data 124 from conductor application 130 by periodically requesting from conductor application 130 any input data 124 that has been received by conductor application 130. In other embodiments, conductor application 130 is configured to “push” input data 124 to hoster application 120 whenever said data is received from actor application 140.
In step 308, hoster application 120 transmits input data 124 received in step 307 to pseudo terminal 126. As described above in step 305, data entered in pseudo terminal 126, which may include input data 124, is transmitted to hoster application 120. It is noted that in some embodiments, some or all of input data 124 may not be echoed back from pseudo terminal 126 to hoster application 120, for example when a password or other confidential input is directed to application program 122.
In the embodiment of method 300 described above, hoster application 120 is configured as the session owner during the shared control session of application program 122. In some embodiments, the session owner can send invitations to other remote users after the shared control session has already started. In addition, the session owner can revoke invitations to the current shared control session and/or change the status of one or more actor applications 140 between read/write and observer only. In one such embodiment, hoster application program 120 revokes an invitation and/or changes status of one or more actor applications 140 by informing conductor 130, which then routes input data 125 and output data 124 to the desired actor applications 140 accordingly. In some embodiments, session ownership can be transferred to one or more of the remote applications 140 some time after the shared control session of application program 122 has begun.
As shown, method 400 begins at step 401, where conductor application 130 monitors a known port, such as port 443, for connection requests.
In step 402, conductor application 130 receives a connection request from hoster application 120. Such connection requests are described above in step 302 of method 300.
In step 403, conductor application 130 may provide an ID and other connection information to hoster application 120 to enable one or more actor applications 140 to uniquely identify and connect to conductor application 130 via actor port 132. In such embodiments, hoster application 120 sends invitation 160 to one or more remote users. Alternatively, in some embodiments, conductor application 130 sends invitation 160 directly to the desired one or more remote users in step 403, shown in
In step 404, conductor application 130 receives a connection request from one or more actor applications 140 to connect to actor port 132.
In step 405, conductor application 130 establishes connection 149. In some embodiments, an authorization protocol is performed with each actor application 140 that requests a connection to actor port 132. In other embodiments, no authorization protocol is required for an actor application 140 to connect with conductor application 130. For example, no authorization protocol may be performed when the user of hoster device 121 has specified that no invitations are required to join the shared control session of application program 122 and is therefore open to any users of actor device 141.
In step 406, conductor application 130 receives output data 125 from hoster application 120 via connection 129.
In step 407, conductor application 130 transmits output data 125 received in step 406 to actor device 141 and actor application 140. Actor application 140, which is running on actor device 141, then displays output data 125 on actor terminal 143 to the user of actor device 141. Thus, output from application program 122, e.g., output data 125, can be displayed to a remote user via conductor application 130.
In step 408, which may occur concurrently with steps 406 and 407, conductor application 130 receives input data 124 via connection 149 from actor application 140. In such embodiments, actor application 140 is configured as a conventional actor application and therefore shares control of application program 122 with hoster application 120. In embodiments in which actor application 140 is designated as an observer application, actor application 140 is not configured to transmit input data 124 to conductor application 130 and can only observe input data 124 and output data 125 that have been directed to pseudo terminal 126. Alternatively, conductor application 130 may be configured to ignore input data 124 received in step 408 from actor applications 140 that have been designated observer only.
In step 409, conductor application 130 transmits input data 124 received in step 408 to hoster application 120. As described above in step 307, in some embodiments hoster application 120 pulls input data 124 from conductor application 130 by periodically requesting input data 124 from conductor application 130. In other embodiments, conductor application 130 is configured to push input data 124 to hoster application 120 whenever said data is received from actor application 140 in step 408.
In the embodiment illustrated in
As the foregoing illustrates, computer-implemented systems 100 and 500 enable two or more remotely located users to simultaneously control an application of interest. Furthermore, each of the remote users can observe both the input provided to the application of interest by the other remote users and the output produced by the application in response to said input. Consequently, multiple users can actively participate in a shared control application. For example, multiple users can investigate a problem associated with the application of interest in an inventory systems, or a “build failure,” or diagnose a problem with a computer system using multiple diagnosers. Or, multiple users can collaborate on the same software project in real time. In yet another example, educational or training sessions can be conducted by a single teacher/instructor with multiple remote students or trainees, where all of the students can observe real-time input to and output from the application of interest. In addition, some or all of the students may have shared control of the application of interest. In another example embodiment, crowd-sourcing is facilitated by configuring computer-implemented system 100 so that remote users do not require invitation 160 to have shared control of application program 122. Consequently, a shared control session can remain active for long periods, and essentially any user can connect to conductor application 130 and contribute to the problem being solved.
In some embodiments, a computer-implemented system similar to computer-implemented systems 100 and/or 500 is configured to enhance collaboration between multiple users sharing control of application program 122. For example, in some embodiments, such a computer-implemented system facilitates file sharing between the user of hoster device 121 and any remote users connected to conductor application 130 via connection 149. One such embodiment is illustrated in
Files 627 and 628 may include, for example, recorded shared control sessions of application program 122, such as recorded input to and output from application program 122. Files 627 and 628 may include icons or textual indicators that denote from which user such input and output originated. In some embodiments, files 627 and 628 include text data and in other embodiments, files 627 and 628 include more complex recordings of a particular shared control session of application program 122. For example, color coding may be used in files 627 and/or 628 to differentiate which inputs were provided by which users. In some embodiments, files 627 and 628 include chat-type text files, so that remote users can efficiently communicate while collaborating on application program 122. In yet other embodiments, files 627 and 628 include files that enable a video and/or audio chat stream to occur during a shared control session of application program 122. Transfer of other types of files between the user of hoster device 121 and one or more actor devices 141 also falls within the scope of the invention.
Local network 710 may include a corporate network, for example, so that any employee of a particular corporation can join in a shared control session of application program 122. In some embodiments, an invitation from hoster application 720 or conductor application 730 is required for a remote user to join in such a shared control session, and in other applications, any user located within local network 710 may join in the shared control session. In either case, computer-implemented system 700 facilitates collaborative work on a single application of interest by multiple users within local network 710.
In sum, embodiments of the invention set forth a computer-implemented system and method for providing shared control of an application by multiple remote users. Advantages of the system and method provided herein include shared control of and access to output from an application of interest by multiple users who may be separated by one or more network firewalls.
In accordance with an embodiment, the non-transitory computer-readable medium may be a magnetic recording medium, a magneto-optic recording medium, or any other recording medium which will be developed in future, all of which can be considered applicable to the present invention in all the same way. Duplicates of such medium including primary and secondary duplicate products and others are considered equivalent to the above medium without doubt. Furthermore, even if an embodiment of the present invention is a combination of software and hardware, it does not deviate from the concept of the invention at all. The present invention may be implemented such that its software part has been written onto a recording medium in advance and will be read as required in operation.
While the foregoing is directed to embodiments of the present invention, other and further embodiments of the invention may be devised without departing from the basic scope thereof, and the scope thereof is determined by the claims that follow.