Patent Publication Number: US-8972543-B1

Title: Managing clients utilizing reverse transactions

Description:
BACKGROUND 
     Many distributed processing systems utilize server/client configurations. According to most such configurations, a server or controller issues commands to various clients. The clients execute the commands and typically provide results of the execution to the controller. One application of server/client configurations is in distributed testing and/or monitoring applications, where each client is instructed to perform all or a portion of a testing and/or monitoring task, such as detecting or simulating a malicious attack, simulating a load, etc. 
     There are various existing communication approaches for implementing client/server communications. According to a message-based approach, the controller sends an instruction message or messages to each client for each action, or portion thereof, that the client is to perform. The clients must provide the controller with a response to each message to validate the success or failure of the request. With most message-based approaches, communications between the controller and the clients are initiated by the controller. Accordingly, the controller must know the identity and location of each client before it can issue an instruction. This increases the complexity of controller implementation and also places practical limitations on the placement of clients. For example, a client placed behind a firewall or network address translation (NAT) device may not be reachable by the controller without considerable overhead complexity and expense. 
    
    
     
       FIGURES 
       Various example embodiments of the present invention are described here by way of example in conjunction with the following figures, wherein: 
         FIG. 1  is a diagram showing one example embodiment of an environment for reverse transaction communications including a controller and various clients. 
         FIG. 2  is a diagram showing one example embodiment of a workflow demonstrating reverse transaction communications between an example client and an example controller. 
         FIG. 3  is a block diagram showing one example embodiment of a request message sent to a controller by a client. 
         FIG. 4  is a block diagram showing one example embodiment of a response message comprising a command to the client. 
         FIG. 5  is a block diagram showing one embodiment of a request message comprising a result of a command provided to the client using a response message. 
         FIG. 6  is a diagram showing one example embodiment of a workflow demonstrating reverse transaction communications between an example client and an example controller where the controller implements a time out command. 
         FIG. 7  is a diagram showing one example of a vertically-scaled environment for utilizing reverse transaction communications, the environment including controllers, clients and a super-controller. 
         FIG. 8  is a diagram showing one embodiment of an environment for utilizing reverse transaction communications in the context of device testing. 
         FIG. 9  is a diagram showing one embodiment of an environment for utilizing reverse transaction communications. 
     
    
    
     DESCRIPTION 
     Various example embodiments are directed to systems and methods for managing communications between a controller and one or more clients utilizing reverse transactions. Messages between the controller and the clients may be formatted according to a transport layer protocol that distinguishes between requests and responses. The controller and clients, however, may utilize the message types in “reverse.” For example, commands from the controller to the clients may be included in messages formatted as “responses” according to the transport layer protocol (e.g., response messages). Results of command execution from clients to the server may be included in messages formatted as “requests” according to the transport layer protocol (e.g., request messages). 
     In various example embodiments, reverse transactions may be initiated by clients. A client may direct a first request message to the controller. The body or payload of the first request message, however, may include data describing the client. Such data may include, for example, an identification of the client, a credential of the client, information describing capabilities of the client, etc. Header information for the first request message may be defined by the transport layer protocol. In various example embodiments, however, the header information includes a network address of the client and/or other connection information, thus allowing the controller to direct messages back to the client. In some example embodiments, the network address and/or other connection information of the client indicated in the header reflects any firewalls and/or network address translation (NAT) devices between the controller and the client, thus making the firewall and NAT devices transparent to the controller. 
     Upon receiving the first request message, the controller may utilize the data describing the client to authenticate the client and select a command for the client to execute. The command may be included in the body of a response message directed to the client. Because, according to the transport layer protocol, the client is waiting for a “response” from the controller, the connection between the controller and the client may be held open until the response message is received. In some embodiments, if there is no task or command for the client for a threshold amount of time after receipt of the first request message, the controller sends a response message comprising a time-out command. The time-out command instructs the client to maintain its connection to the controller and await an additional response message including an additional command. Once the client receives the response message, including the command, it may execute the command and provide results of the execution to the controller in a subsequent request message. The subsequent request message may also indicate that the connection between client and controller is to be held open until the controller has an additional task for the client. 
     The use of reverse transactions can provide various advantages in different application settings. For example, the use of reverse transactions may simplify the placement of clients, as it may not be necessary for the controller to have information about the existence and location of each client test engine prior to use. Also, controller overhead may be reduced as it may not be necessary for the controller to connect to the inside of NAT and/or firewall environments to contact clients therein. 
     According to various example embodiments, reverse transactions are used to manage distributed testing and/or monitoring systems and applications. For example, each client may implement a test engine configured to perform tasks related to testing a device under analysis. Such testing may include scale testing for simulating a load on the device under analysis. For example, each client may be configured to, on command from the controller, simulate a number of connections to the device under analysis. Also, testing may include mutation and/or fuzz testing where messages to the device under analysis are deliberately modified to simulate a malicious attach. 
     Reference will now be made in detail to several example embodiments, including embodiments showing example implementations of controllers, clients, systems of controllers and clients as well as methods for implementing reverse transaction communications. Wherever practicable similar or like reference numbers may be used in the figures and may indicate similar or like functionality. The figures depict example embodiments of the disclosed systems and methods for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative example embodiments of the systems and methods illustrated herein may be employed without departing from the principles described herein. 
       FIG. 1  is a diagram showing one example embodiment of an environment  100  for reverse transaction communications including an example controller  102  and various clients  104 . The controller  102  and clients  104  may be in communication with one another via a network  106 . The network  106  may be and/or comprise any suitable type of wired and/or wireless network. In some embodiments, the Internet may make up all or a part of the network  106 . As described in more detail within, the network  106  may comprise various firewalls and/or NAT devices positioned between the controller  102  and the clients  104 .  FIG. 1  also shows an example client  104 ′ showing additional details that some clients may have. For example, the client  104 ′ comprises an application program interface (API)  110 . The API  110  may serve as an interface for processing commands received from the controller  102 , for example, as described herein. 
     Before providing detailed descriptions of reverse transaction communications between various controllers  102  and clients  104 , a brief description of suitable transport layer protocols is provided. Transport layer protocols for reverse transaction communications may include any protocol that distinguishes between requests and responses and allows a message body and/or payload information that can include client and/or command information as described herein. In some example embodiments, the selected transport layer protocol allows for the association of related request and response messages. For example, a device sending a request may expect to receive an associated response. A partial list of example protocols that may be used include, for example, hypertext transfer protocol (HTTP), hypertext transfer protocol secure (HTTPS), Session Initiation Protocol (SIP), file transfer protocol (FTP), media gateway control protocol (MGCP), etc. 
       FIG. 2  is a diagram showing one example embodiment of a workflow demonstrating reverse transaction communications between an example client  104  and an example controller  102 . The client  104  may send an initial request  202  to the controller  102 . In some example embodiments, the request  202  may initiate communication between the controller  102  and the client  104 . The request  202  may be formatted as a request according to the transport layer protocol.  FIG. 3  is a block diagram showing one example embodiment of a request message  202 . The request message  202  comprises a header  302  and a body or payload  303 . In various example embodiments, the request message may be a POST request according to the HTTP transport level protocol. 
     The content of the header  302  may be determined based on the particular transport layer protocol selected. For example, in various example embodiments, the header  302  may comprise routing information for the message  202  including network address and/or connection information identifying the controller  102  and the client  104 . It will be appreciated that if the request message  202  traverses a firewall and/or NAT device, it may arrive at the controller  102  with modified network and/or connection information for the client  104 . The modified connection information, however, may be utilized by the controller  102  to direct a response message to the client  104 , for example, as described herein below. In some example embodiments, the header  302  comprises additional information including, for example, information about the size and/or other properties of the body  303 . 
     The body or payload  303  of the request message  202  may comprise various information describing the client  104 . The body  303  itself may be arranged according to any suitable protocol or format. In some example embodiments, the body  303  is arranged according to the JavaScript Object Notation (JSON) format, with or without a schema. For example, when the transport layer protocol is HTTP or HTTPS, the body  303  may be arranged according to JSON. In addition to or instead of JSON, the body  303  may be organized according to various other protocols or formats including, for example, eXtensible Markup Language (XML), YAML Ain&#39;t Markup Language (YAML), Binary JSON (BSON), or any other publicly available and/or proprietary protocol, serialization or marshaling method. In various example embodiments, the body  303  comprises various data containers for information describing the client  104 . As illustrated in  FIG. 3 , the body comprises an identification container  304 , a credential container  306 , an about container  308  and a response container  310 . As the body  303  sits on top of the underlying transport layer protocol, transport layer operations such as message chunking and compression may be handled by the underlying transport layer protocol, obviating the need to handle these communication aspects in the body  303 . 
     The identification container  304  may comprise an “id” or unique identifier of the client  104  (e.g., a unique number or other string used to identify the client  104  in a computer device). For example, when the client  104  is executed on a computer device that also executes other clients, the identifier may distinguish the client  104  from other clients executing on the common computer device. The credential container  306  may include a client credential that allows the client to be authenticated to the server. For example, in some example embodiments, the credential container  304  comprises an encrypted credential that may be decrypted by the controller  102  to securely verify the identity of the client  102 . Where the client utilizes an API  110 , the credential container  304  may comprises an API key that can be utilized by the controller  102  to provide commands to the client  104  via the API  110 . Additionally, in some example embodiments, the credential container  304  may comprise instructions for additional handshaking steps that may be performed by the controller  102  and client  104  for each to verify the identity of the other. 
     The about container  308  comprises information about the capabilities of the client  104 . For example, the about container  308  may comprise data describing the types of commands that the client  104  is capable of executing. When the client  104  executes one or more test engines, the about container  308  may describe the test engines and the type of test or tests that the test engines can perform, as described herein below. The optional response container  310  may be reserved for information describing results of a command performed by the client  104 . As the request message  202  may initiate reverse transaction communication between the client  104  and controller  102 , the response container  310  may be blank. 
     An example request message  202  is provided below. In the provided example, the transport layer protocol is HTTP and the body is organized according to the JSON protocol: 
     POST/_xxxx HTTP/1.1 
     Content-Type: application/json 
     Connection:keep-alive 
     . . 
     { 
     “version”:“1.0.0”, 
     “id”:1, 
     “credential”:“SOME_CLIENT_KEY”, 
     “about”:{ . . . },//capabilities 
     “response”:{ } 
     } 
     The portion of the example request message  202  prior to the “{ }” is a partial representation of the header  302 . The portion within the “{ }” represents the message body  303  and comprises an id container  304 , a credential container  306 , an about container  308  and an optional response container  310 , which is empty in the provided example for the reasons described above. It will be appreciated that various request messages  202  may comprise information and information containers in addition to  304 ,  306 ,  308 ,  310  described above. For example, the example message  202  provided above comprises a version container that may indicate the version of the protocol used to organize the body (e.g., JSON). 
     Referring now back to  FIG. 2 , the controller  102  may receive the request message  202  and, at  204 , may wait for a command to provide the client  104 . According to the transport layer protocol of the message  202 , the client  104  may expect a response message associated with the request message. Accordingly, the controller  102  may hold the connection with the client  104  until there is a command to provide to the client  104 . The controller  102  may determine a command for the client  104  according to its own process (e.g., based at least in part on the capabilities of the client  104 ). Also, in some example embodiments in the context of a distributed testing, the controller  102  may provide the client  104  with a command for performing a testing related task (e.g., generating and/or applying a mutation or fuzz test, initiating a connection with a device under analysis for a scale test, etc.). 
     When the controller  102  determines a command for the client  104 , the controller  102  may generate a response message  206  and transmit the same to the client. The response message  206  may be organized according to the transport layer protocol as a response. In various example embodiments, the response message  206  is tied to the request message  202  via the transport layer protocol. For example, header information of the response message  206  may associate it with the request message  202  so that the client  104  may determine that the response message  206  is in reply to the request message  202 . 
     Although the response message  206  is configured as a response according to the transport layer protocol, it may include the command to the client  104 . Accordingly, the command may “piggyback” on the transport layer protocol response.  FIG. 4  is a block diagram showing one example embodiment of the response message  206  comprising a command to the client  104 . The message  206  comprises a header  402  and a body/payload  403 . Parameters of the header  402  may be determined, for example, by the transport layer protocol utilized. For example, the header  402  may comprise information describing network address and connection information for the controller  102  and the client  104 . In some example embodiments, the header  402  also comprises data describing the body  403  such as, for example, a size, etc. 
     The body or payload  403  comprises various information for delivering the command to the client  104  and may be organized according to any suitable protocol such as, for example, JSON. In the example embodiment shown in  FIG. 4 , the body  403  comprises a credential container  404 , a command container  406 , a timeout container  408 , a CID container  410 , and a parameter container  412 . The credential container  404  may comprise information describing a credential of the controller  102 . For example, the credential information may be utilized by the client  104  to verify the identity of the controller  102  upon receipt of the response. One type of credential information that may be used includes an encrypted credential that may be decrypted by the client  104  to verify the identity of the controller  102 . 
     The time-out container  408  may comprise a long-poll time out value. The long-poll time out value may indicate to the client  104  how long it should wait for a response message (such as message  206 ) after sending a request (such as the request message  202 , and the request message  210  described below). If the specified time has passed, the client  104  may no longer expect a response message and, for example, may send a new request message  202 . 
     The command container  406  may comprise data describing the command to be executed by the client  104 . For example, the command may be a server command against the client and may be processed by the client  104 , with the corresponding result returned to the controller  102 . The CID container  410  may comprise a unique identifier for the command stored at the command container  406 . The parameter container  412  may comprise any arguments to be utilized by the client  104  in executing the command. For example, the parameter container  412  may comprise a start time at which the client  104  is to begin execution of the command. For example, when multiple clients  114  are to perform certain tasks simultaneously, it may be desirable for all of the implicated clients  114  to begin execution at the same time. Also, in some embodiments, the arguments may include a script to be executed by the client  114  to execute all or part of a command and/or a universal resource locator (URL) or other network address indicating the location of such a script. In example embodiments where the client  104  implements an API, the parameter container  412  may comprise all or a portion of an API key providing the controller  102  with access to the client API (e.g., such as client API  110 ). 
     An example response message  206  comprising a command is provided below. In the provided example, the transport layer protocol is HTTP and the body is organized according to the JSON protocol: 
     HTTP/1.1 200 OK 
     Content-Type: application/json 
     Content-Length: . . . . 
     { 
     “credential”:“SERVER_CREDENTIAL”, 
     “timeout”:30, 
     “command”:“start”, 
     “cid”:“start — 1248” 
     “params”:{ 
     “run_id”:“test — 10238”, 
     “iteration”:false, 
     “stats”:false 
     } 
     } 
     The portion of the example response messages  206  prior to the outer-most “{ }” is a partial representation of the header  402 . The portion within the outer “{ }” represents the message body  403  and comprises a credential container  404 , a timeout container  408 , a command container  406 , a CID container  410 , and a parameter container  412 . It will be appreciated that various embodiments of the messages  206  may comprise additional containers and additional information other than that in the examples provided herein. 
     Referring again back to  FIG. 2 , the client  104  may process the command indicated at the command container  406  at  208  (e.g., according to the parameters of the response message  206 ). Upon completion of the command, the client  104  may generate and transmit a second request message  210  comprising results of the execution of the command to the controller  102 . The second request message  210 . As the second request message  210  is a new request message, it may not be associated with the response message  206  including the command, at least according to the transport layer protocol. The controller  102  may match the second request message  210  to its associated response message  206  utilizing the command id, as described herein below. 
       FIG. 5  is a block diagram showing one embodiment of the request message  210  comprising a result of a command provided to the client using the response message  206 . Like the request message  202 , the request message  210  may be configured as a request under the utilized transport layer protocol. The request message  210  may comprise a header  502  similar to the header of the message  202  described above. The body  503  of the message  210  may also be similar to the body  303  of the message  202  described above. For example, the body  503  of the message  210  may comprise an identification container  504 , a credential container  506 , an about container  508 , and a response container  510 . The response container  510  of the message  210 , however, may comprise and/or be associated with additional containers making up a response to the command provided by the response message  206 . For example, a command container  512  and a CID container  514  may comprise the command and CID received by the client  104  via the message  206 . A result container  510  may comprise results of the execution of the command. 
     An example request message  210  is provided below. In the provided example, the transport layer protocol is HTTP and the body is organized according to the JSON protocol: 
     POST/_xxxx HTTP/1.1 
     Content-Type: application/json 
     Connection:keep-alive 
     { 
     “version”:“1.0.0”, 
     “id”:1, 
     “credential”:“SOME_CLIENT_KEY”, 
     “about”. { . . . },//capabilities 
     “response”:{ 
     “command”:“start”, 
     “cid”:“start — 1248”, 
     “result”: {“okay”:true, “stats”:{ . . . } } 
     } 
     } 
     Again, the portion of the example request message  210  prior to the “{ }” is a partial representation of the header. The portion within the outer “{ }” represents the message body  503  and comprises an id container  504 , a credential container  506 , an about container  508  and a response container  510 . In contrast to the request message  202 , the example of the request message  210  comprises data within the response container  510 . For example, the response container  510  comprises the command container  514 , the CID container  514  and the result container  510 , as described above. 
     Referring once again back to  FIG. 2 , the controller  102  may receive the request message  210  and process the results contained therein at  212 . As described above, the transport layer protocol may not associate the response message  206  including the command with the prior request message  202  including the response to the command. In various example embodiments, however, the controller  102  may associate the messages  206 ,  210  based on a common CID included in each. Also, because of the request/response nature of the underlying transport layer protocol, the client  104  may expect a “response” to the request message  210 . Accordingly, the controller  102  may keep the connection with the client  104  open, as described above, until a new command is determined for the client  104 . When a new command is ready, the process may repeat itself, with a new response message (similar to the message  206 ) being generated and transmitted to the client  104  and a new request message (similar to the message  210 ) being returned in reply. 
       FIG. 6  is a diagram showing one example embodiment of a workflow demonstrating reverse transaction communications between an example client and an example controller where the controller implements a time out command. In some example embodiments, as described above, the client  104  may wait a threshold time-out period after sending the initial request message  202  and/or a subsequent request message such as  210 . If no response message is received during the time out period (e.g., a response message such as  206  comprising a command), then the client  104  may cease to expect a response. For example, the client  104  may send a new request message, such as  202  and/or hibernate. Accordingly, the controller  102  may be programmed to keep all clients  104  active. For example, if the wait for a command at  204  approaches the client&#39;s time out period, the controller  102  may provide the client  104  with a response message  602  comprising a time-out command. The response message  602  may be similar to the response message  206 . Upon receipt of the response message  206 , the client  104  may send a new request message  603  to the controller  102 . The request message  603  may have any suitable payload. In some example embodiments, the payload of the message  603  is a response to the time-out command and may include, for example, a default payload, a status of the client  104 , etc. When a new command for the client  104  is found at  204 ′, the response message  206  may be sent, as described above. In various example embodiments, the response message  206 , as illustrated in  FIG. 6 , is a response to the request message  603 , according to the transport layer protocol. In this way, the client  104  may continue to expect a response message including a command after its threshold time-out period has run. 
     The example communications between a controller  102  and client  104  described above may be scaled in any suitable manner. For example, the interactions described above may be scaled horizontally, as the controller  102  may simultaneously manage multiple clients  104  in the manner described above, for example, as illustrated in  FIG. 1 . Also, in some embodiments, the interactions described above may be scaled vertically.  FIG. 7  is a diagram showing one example of a vertically-scaled environment for reverse transaction communications including controllers  102 , clients  104  and a second layer or super-controller  702 . The various components  702 ,  102 ,  104  may communication with one another via a network such as the network  106  (not shown in  FIG. 7 ). The super controller  702  may utilize reverse transaction communications to provide commands to the various controllers  102 , for example, in the same way that controllers  102  provide commands to clients  104  as described above. Commands provided to the various controller  102  may be utilized by the controllers  102  to select commands for various clients  104  in communication with the controllers  102 . Also, it will be appreciated that some clients  104  may be in communication with sub-clients  704 . For example, a client  104  in communication with sub-clients  704  may be programmed to operate relative to the sub-clients  704  in a manner similar to which the controller  102  operates relative to its various clients  104 . For example, clients  104  in communication with sub-clients  704  may break commands received from the controller  102  into discrete tasks. Some or all of the tasks may be “assigned” to one or more sub-clients  704  (e.g., utilizing response messages provided to the sub-clients  704  in response to request messages received from each sub-client  704 ). 
     It will be appreciated that reverse transaction communications, as described herein, may provide various security-related advantages. For example, clients  104  may operate under the direction of a controller  102  with knowledge only of the controller&#39;s universal resource locator (URL) or other network address. This may minimize the amount of sensitive information stored at each client  104  that might fall into the hands of a malicious user (e.g., for attacking the distributed system). Also, as described herein, credentials of the originating party may be included in both the messages from the controller  102  to the client  104  and the messages from the client  104  to the controller  102 . Accordingly, the respective components  102 ,  104  may block access to their counter-party when the country-party&#39;s credentials are either missing or corrupted. Additional identity verification between hosts  102  and clients  104  may be performed in various example embodiments. Also, in some example embodiments, the underlying transport layer protocol may be selected to enhance security. For example, HTTPS, or another encryption-supporting protocol may be utilized. In some example embodiments, secure and non-secure transport layer protocols may be utilized together. For example, the client  104  may be configured to switch the controller URL from an HTTP URL to an HTTPS URL when a message is sensitive. For example, some request messages  210  including command responses may be sensitive, such that a secure protocol is desirable. 
     In various example embodiments, the controller  102  and/or the clients  104  may be configured for operation in the absence of communication with their counter-party or counter-parties. For example, when a connection between the controller  102  and a client  104  is closed, the controller  102  may be notified according to the underlying transport layer protocol. If the underlying transport layer protocol does not support a disconnect notification, the controller  102  may timeout a callback of a command and save the command until another suitable worker is available. In some example embodiments, the controller  102  may be configured to timestamp responses including commands, such as  206 . If a client  204  is tardy in replying to a command, the controller  102  may identify a stale reply by comparing the CID of a request including a result, such as  210 , to an associated time stamp. When a controller  102  connection is disconnected, a client  104  may be notified from the transport layer protocol implementation, and may re-send a failed request message  202 ,  210  at a later time. If the underlying transport layer protocol does not support a connection-dropped notification, the client  104  may exceed its time out period for receiving a response, such as  206 . When this occurs, the client may wait until the controller  102  is available again. 
     In some example embodiments, it may be desirable for some or all of the clients  104  to execute commands in a synchronized manner. For example, some device testing tasks require all or a portion of the clients  104  to start a command, complete a command, and/or perform an intermediate command step at the same time. Accordingly, the controller  102  may be configured to synchronize the clocks of the various clients  104  with which the controller  102  is communicating. For example, some or all of the responses messages  206  from the server may include clock synchronization data that may be utilized by the respective clients  104  to update their own clocks to match that of the controller  102 . 
       FIG. 8  is a diagram showing one embodiment of an environment  800  for utilizing reverse transaction communications in the context of device testing. The environment  800  comprises the controller, clients  104  and network  106  similar to that of the environment  100  described herein above. The environment  800  also comprises devices under analysis (DUA)  802  that may be subjected to various tests by the clients  104  (e.g., in response to commands provided by the controller  102  as described above). The DUA&#39;s  802  may represent software and/or hardware. Such software may include, for example, applications, operating systems, and/or communications systems. Such hardware may include, for example, one or more computer devices. A computer device may be, for example, a switch, a bridge, a router (including wireline or wireless), packet filter, firewall (including stateful or deep inspection), Virtual Private Network (VPN) concentrator, Network Address Translation (NAT)-enabled device, proxy (including asymmetric), intrusion detection/prevention system, network protocol analyzer, etc. A DUA  802  may also be multiple devices that are communicatively coupled to form a system or network of devices. For example, a DUA  802  may be two firewall devices that establish an encrypted tunnel between themselves. Different DUA&#39;s  802  may communicate with one another via the network  106  although it will be appreciated that, in various example embodiments, the network  106  may form all or a part of a DUA  802 . 
     To test the DUA&#39;s  802 , the controller  102  may be configured to provide commands to the various clients  114 , as described herein above, wherein each command instructs the respective client to perform all or part of a testing task. Example testing tasks to be performed on DUA&#39;s  802  may include, for example, monitoring tasks (e.g., Secure Shell (SSH) channel monitoring, Simple Network Management Protocol (SNMP) monitoring, protocol instrumentation, etc.), or interactive tasks (e.g., concurrency scale tests, network performance tests, fuzz tests, etc.). Some testing tasks may be performed individually by a single client  104 , while other testing tasks may be performed collectively by multiple clients  104  working in conjunction with one another. 
       FIG. 9  is a diagram showing one embodiment of an environment  900  for utilizing reverse transaction communications. The environment  900  is provided to demonstrate network configurations in which reverse transaction communications may be advantageous. For example, the controller  102  shown in  FIG. 9  is in communication with various clients  104  via a network  902 . The network  902 , for example, may be and or comprise a wide area network (WAN) such as the Internet. The controller  102  may utilize the network  902  to provide commands to the clients  104 , for example, in the manner described herein. Various DUA&#39;s  802  are also shown communicating directly on the network  902 . For example, when the controller  102  and clients  104  are utilized in conjunction with a distributed testing system, the clients  104  may be configured to perform various testing tasks on the DUA&#39;s  802  in response to commands from the controller  102 . 
     The environment  900  also includes an optional set of clients  104   a  that communicate with the controller  102  via the network  902  and a network address translation (NAT) device  904 . As described above, reverse transaction communications may allow the controller  102  to communicate with the clients  104   a  without requiring the controller  102  to connect to any devices inside of the NAT device  904 . For example, a request message  202 ,  210  from a client  104   a  may have its address information modified as the request message  202 ,  210  is routed through the NAT device  904 . Because the requests  202 ,  210  originate from the clients  104   a , and because the NAT modification takes place at the transport layer, the NAT device  904  may be transparent to the controller. Optional DUA&#39;s  802   a  are also illustrated as separated from the network  902  by the NAT device  904 . In various example embodiments, the clients  104   a  may receive commands to perform testing tasks on the DUA&#39;s  802   a.    
     The environment  900  may also include an optional set of clients  104   b  that communicate with the controller  102  via the network  902  and a LAN or other network  908  that is behind a firewall  906 . Again, reverse transaction communications may allow the controller  102  to communicate with the clients  104   b  without requiring the controller to connect to any devices inside of the firewall  906 . For example, because communications between the clients  104   b  and the controller  102  (e.g., the requests  202 ,  210 ) may be initiated by the clients  104   b , the controller  102  may simply reply to access the clients  104   b . Optional DUA&#39;s  802   b  are also illustrated as communicating on the LAN  908  behind the firewall  906 . In various example embodiments, the clients  104   b  may receive commands to perform testing tasks on the DUA&#39;s  802   b.    
     Different computer systems components described herein (e.g., the controller  102 , the clients  104 ,  104 ′,  104   a ,  104   b , the DUA&#39;s  802 ,  802   a ,  802   b , the super controllers  702 , etc., may be executed by computer devices in communication with one another according to any suitable method. For example, in some example embodiments, some or all of the computer systems described herein may be in communication with one another via a network or networks, such as the networks  106 ,  902 ,  908  described herein. The network or networks may operate according to any suitable wired or wireless communication protocol and may utilize any suitable hardware or software. In some example embodiments, the network or networks may include, a wide area network (WAN) such as the Internet, a local area network (LAN), etc. 
     According to various example embodiments, the testing tasks performed by the clients  104  may be of any suitable type. For example, one or more clients  104  may be configured, as described herein, to perform monitoring tasks and interactive tasks. In monitoring testing tasks, the clients  104  may observe the DUA&#39;s  802  and record properties describing the DUA&#39;s  802 . In various example embodiments, each DUA  802  may be observed by a separate client  104  and/or by multiple clients  104 . In interactive tasks, the clients  104  may interact with the DUA&#39;s  802  to observe the response and/or find a limit of the capabilities of the DUA&#39;s  802 . 
     Examples of monitoring testing tasks may include Secure Shell (SSH) channeling monitoring, Simple Network Management Protocol monitoring, and Protocol Instrumentation. According to SSH channel monitoring, one or more clients  104  may connect to a DUA  802  and execute a periodic command for the purpose of establishing system health. The command may, for example, check a status of a process, a level of central processor unit (CPU) utilization, a level of memory utilization, etc. The connection between the one or more clients  104  and the DUA  802  may be made according to an SSH channel. According to SNMP monitoring, one or more clients  104  may collect statistics from a Management Information Base of a DUA  802 . Example statistics may include, for example, CPU and memory utilization, error counts, etc. According to Protocol Instrumentation, one or more clients  104  may collect statistics and/or flag errors encountered during periodic checkpoint exchanges with the DUA  802  using valid protocol transactions. Although each of the monitoring testing tasks is described herein with reference to a single DUA  802 , it will be appreciated that these testing tasks may be ramped up using multiple clients  104  (e.g., a group of clients  104 ). For example, a group of clients  104  may be assigned a testing task requiring the group to monitor a corresponding group of DUA&#39;s  802 . 
     Interactive testing tasks may generally comprise testing tasks where the client  104  or engine  108  provide simulated interactions (e.g., communications and/or connections) with the DUA&#39;s  802  to test the capacity and/or security of the DUA&#39;s  802 . Utilizing groups of clients  104  to perform load testing may increase the volume and/or the variety of types of communications and/or connections that may be sent to and/or initiated with the DUA&#39;s  802 . Examples of interactive testing tasks include concurrency scale tests, network performance tests, fuzz tests as well as other load and/or security-related tests. According to concurrency scale tests, a client  104  or clients  104  may generate high levels of connections to a DUA  802  utilizing various transport protocols including, for example Transmission Control Protocol (TCP), User Datagram Protocol (UDP) and Secure Sockets Layer (SSL). The clients  104  may collect statistics for the attempted connections including, for example, pass rates, timeouts, errors, latencies, etc. According to network performance testing tasks, the client  104  or engines may generate high levels of network traffic representing varied types of transactions. Statistics may be kept for bytes and packets sent and received on each interface. Examples for generating and executing scale and/or concurrency testing based on scenarios are provided in commonly-assigned U.S. patent application Ser. No. 13/101,728 (the &#39;728 application) titled, “Generating Communication Protocol Test Cases Based On Network Traffic,” filed on May 5, 2011 and U.S. patent application Ser. No. 13/118,155, (the &#39;155 application) titled, “Scenario Based Scale Testing,” filed on May 27, 2011, both of which are incorporated by reference herein in their entireties. 
     According to a fuzz test or mutation test, a client or clients  104  may generate invalid, unexpected and/or random data within the structure of one or more network protocols. The invalid, unexpected and/or random data is then provided to DUA&#39;s  802 . The test engine or engines  108  may identify the types of invalid, unexpected or random data cause different DUA&#39;s  802  to fail, thus identifying vulnerabilities of the DUA&#39;s  802 . Invalid, unexpected and/or random data may be generated in any suitable manner. Different types of fuzz testing tasks may include structure attacks, semantics attacks and state attacks. According to a structure attack, the clients  104  generate messages that contain values and/or parameters that violate an intended protocol. Types of structure attacks include, for example, empty-field, empty-message, extra-data, incomplete, invalid-count, invalid-enum (enumeration), invalid-eol (end-of-line), invalid-field, invalid-index, invalid-length, invalid-offset, invalid-syntax, invalid-type, invalid-utf8 (Unicode Transformation Format), missing-data, missing-field, mixed-case, overflow, repeated-field, too-many-fields, truncated, underflow, wrong-encoding, fmt-string (format), fragmented-field, invalid-encoding, invalid-field, invalid-ip (IP address), invalid-path, invalid-string, recursion, self-reference, and null-char (character), etc. 
     According to a semantics attack, the clients  104  may send the DUA&#39;s  802  messages that are technically correct, but nonetheless unexpected. For example, one type of semantics attack may involve a message that indicates an invalid (e.g., non-existent) resource, such as a printer. This can cause the DUA  802  to hang or crash unexpectedly. Another example of a semantics attack may be a network packet with a source Internet Protocol (IP) address of “all-broadcast.” If the DUA  802  were to respond to such a packet, it would generate enough packets to flood the network. According to a state attack, the clients  104  may generate messages that are semantically correct, but incorrect based on the expectations of the device. For example, one type of state attack may involve the clients  104  sending messages that are out-of-order (e.g., with respect to the type of message the DUA  802  is expecting to receive). Examples for generating test cases for fuzz and/or mutation attacks are described in commonly owned U.S. patent application Ser. No. 11/351,309, titled “Portable Program for Generating Attacks on Communication Protocols,” filed Feb. 10, 2006, and U.S. patent application Ser. No. 11/351,403, titled “Platform for analyzing the security of communication protocols and channels”, also filed Feb. 10, 2006, the disclosures of which are incorporated herein by reference in their entireties. 
     In some example embodiments, testing tasks executed by clients  104  as described herein may be utilized to test the implementation of a communication protocol using one or more test cases. A test case generally includes one or more message exchanges between two or more entities (e.g., two devices or two processes). A test case (e.g., the messages that are exchanged) can be generated manually or automatically, as described in commonly-assigned U.S. patent application Ser. No. 11/514,809, filed Sep. 1, 2006, titled “Automated Generation of Attacks for Analyzing the Security of Communication Protocols and Channels” (the &#39;809 Application), which is incorporated by reference herein in its entirety. 
     A protocol is generally defined by a specification. The specification can be expressed in a variety of formats, such as an Internet Engineering Task Force (IETF) Request for Comments (RFC), Web Services Description Language (WSDL), Backus-Naur Form (BNF), Augmented BNF (ABNF), regular expressions, Interface Definition Language (IDL), Document Type Definition (DTD), Management Information Base (MIB), eXtended Markup Language (XML) schema, eXternal Data Representation (XDR), and Abstract Syntax Notation 1 (ASN.1). The &#39;809 Application describes software programs that parse machine-readable protocol specifications and generate test cases based on the specifications. 
     Other types of interactive testing tasks may involve general tests of the overall security of the device or DUA&#39;s  802 . Examples of such tasks may include, for example, negotiating a lower (e.g., less secure) encryption algorithm, dictionary attacks (brute forcing commonly-used passwords), resource exhaustion, identifying misconfiguration of the DUA  802 , identifying mechanisms for sending messages through the DUA  802  that bypass various security checks, and detecting insecure implementations of standard protocols and information disclosure. 
     Various communications are described herein between computer hardware and/or software components such as, for example, the controller  102 , the clients  104 ,  104 ′,  104   a ,  104   b , the DUA&#39;s  802 ,  802   a ,  802   b , etc. When communications between computer components takes place over the Internet or other public network, it will be appreciated that these communications may be encrypted. For example, one or more of the systems may utilize an asymmetric or public key infrastructure (PKI) method. According to a PKI system, each system may have a public key that may be used for encrypting messages and a private key that may be used for decryption. The public key may be provided to any systems having need to send data to the first system. The data may be encrypted with the public key such that it may only be decrypted with the private key, which may be kept secret by the receiving system. In this manner, all communications between the various systems may be decrypted only by their intended recipients. 
     The examples presented herein are intended to illustrate potential and specific implementations of the present invention. It can be appreciated that the examples are intended primarily for purposes of illustration of the invention for those skilled in the art. No particular aspect or aspects of the examples are necessarily intended to limit the scope of the present invention. For example, no particular aspect or aspects of the examples of system architectures, methods or processing structures described herein are necessarily intended to limit the scope of the invention. Also, while specific testing applications have been described herein, it will be appreciated that the applications provided according to the description herein may include other testing applications as well as non-testing applications. 
     It is to be understood that the figures and descriptions of the present invention have been simplified to illustrate elements that are relevant for a clear understanding of the present invention, while eliminating, for purposes of clarity, other elements. Those of ordinary skill in the art will recognize, however, that these sorts of focused descriptions would not facilitate a better understanding of the present invention, and therefore, a more detailed description of such elements is not provided herein. 
     Moreover, the processes associated with the present example embodiments may be executed by programmable equipment, such as computers. Software or other sets of instructions may be employed to cause programmable equipment to execute the processes. The processes may be stored in any storage device, such as, for example, a computer system (non-volatile) memory, an optical disk, magnetic tape, or magnetic disk. Furthermore, some of the processes may be programmed when the computer system is manufactured or via a computer-readable memory medium. 
     It can also be appreciated that certain process aspects described herein may be performed using instructions stored on a computer-readable memory medium or media that direct a computer or computer system to perform process steps. A computer-readable medium may include, for example, any non-transitory media such as, for example, memory devices such as diskettes, compact discs of both read-only and read/write varieties, optical disk drives, and hard disk drives. A computer-readable medium may also include memory storage that may be physical, virtual, permanent, temporary, semi-permanent and/or semi-temporary. It will be appreciated that the term non-transitory refers to the medium and not to any data stored thereon. For example, a random access memory (RAM) is non-transitory, although the data stored thereon may change regularly. 
     A “computer,” “computer device,” “machine,” “computer device,” “host,” “engine,” or “processor” may be, for example and without limitation, a processor, microcomputer, minicomputer, server, mainframe, laptop, personal data assistant (PDA), wireless e-mail device, cellular phone, pager, processor, fax machine, scanner, or any other programmable device configured to transmit and/or receive data over a network. Computer systems and computer-based devices disclosed herein may include memory for storing certain software applications used in obtaining, processing, and communicating information. It can be appreciated that such memory may be internal or external with respect to operation of the disclosed example embodiments. The memory may also include any means for storing software, including a hard disk, an optical disk, floppy disk, ROM (read only memory), RAM (random access memory), PROM (programmable ROM), EEPROM (electrically erasable PROM) and/or other computer-readable memory media. 
     In various example embodiments of the present invention, a single component may be replaced by multiple components, and multiple components may be replaced by a single component, to perform a given function or functions. Except where such substitution would not be operative to practice embodiments of the present invention, such substitution is within the scope of the present invention. Any of the servers or computer systems described herein, for example, may be replaced by a “server farm” or other grouping of networked servers (e.g., a group of server blades) that are located and configured for cooperative functions. It can be appreciated that a server farm may serve to distribute workload between/among individual components of the farm and may expedite computing processes by harnessing the collective and cooperative power of multiple servers. Such server farms may employ load-balancing software that accomplishes tasks such as, for example, tracking demand for processing power from different machines, prioritizing and scheduling tasks based on network demand, and/or providing backup contingency in the event of component failure or reduction in operability. 
     Various example embodiments of the systems and methods described herein may employ one or more electronic computer networks to promote communication among different components, transfer data, or to share resources and information. Such computer networks can be classified according to the hardware and software technology that is used to interconnect the devices in the network, such as optical fiber, Ethernet, wireless LAN, HomePNA, power line communication or G.hn. The computer networks may also be embodied as one or more of the following types of networks: local area network (LAN); metropolitan area network (MAN); wide area network (WAN); virtual private network (VPN); storage area network (SAN); or global area network (GAN), among other network varieties. 
     For example, a WAN computer network may cover a broad area by linking communications across metropolitan, regional, or national boundaries. The network may use routers and/or public communication links. One type of data communication network may cover a relatively broad geographic area (e.g., city-to-city or country-to-country) which uses transmission facilities provided by common carriers, such as telephone service providers. In another example, a GAN computer network may support mobile communications across multiple wireless LANs or satellite networks. In another example, a VPN computer network may include links between nodes carried by open connections or virtual circuits in another network (e.g., the Internet) instead of by physical wires. The link-layer protocols of the VPN can be tunneled through the other network. One VPN application can promote secure communications through the Internet. The VPN can also be used to separately and securely conduct the traffic of different user communities over an underlying network. The VPN may provide users with the virtual experience of accessing the network through an IP address location other than the actual IP address which connects the access device to the network. 
     Computer networks may include hardware elements to interconnect network nodes, such as network interface cards (NICs) or Ethernet cards, repeaters, bridges, hubs, switches, routers, and other like components. Such elements may be physically wired for communication and/or data connections may be provided with microwave links (e.g., IEEE 802.12) or fiber optics, for example. A network card, network adapter or NIC can be designed to allow computers to communicate over the computer network by providing physical access to a network and an addressing system through the use of MAC addresses, for example. A repeater can be embodied as an electronic device that receives and retransmits a communicated signal at a boosted power level to allow the signal to cover a telecommunication distance with reduced degradation. A network bridge can be configured to connect multiple network segments at the data link layer of a computer network while learning which addresses can be reached through which specific ports of the network. In the network, the bridge may associate a port with an address and then send traffic for that address only to that port. In various example embodiments, local bridges may be employed to directly connect local area networks (LANs); remote bridges can be used to create a wide area network (WAN) link between LANs; and/or, wireless bridges can be used to connect LANs and/or to connect remote stations to LANs. 
     In various example embodiments, a hub may be employed which contains multiple ports. For example, when a data packet arrives at one port of a hub, the packet can be copied unmodified to all ports of the hub for transmission. A network switch or other devices that forward and filter OSI layer 2 datagrams between ports based on MAC addresses in data packets can also be used. A switch can possess multiple ports, such that most of the network is connected directly to the switch, or another switch that is, in turn, connected to a switch. The term “switch” can also include routers and bridges, as well as other devices that distribute data traffic by application content (e.g., a Web URL identifier). Switches may operate at one or more OSI model layers, including physical, data link, network, or transport (e.g., end-to-end). A device that operates simultaneously at more than one of these layers can be considered a multilayer switch. In certain example embodiments, routers or other like networking devices may be used to forward data packets between networks using headers and forwarding tables to determine an optimum path through which to transmit the packets. 
     As employed herein, an application server may be a server that hosts an API, such as the API  110 , to expose business logic and business processes for use by other applications. Examples of application servers include J2EE or Java EE 5 application servers including WebSphere Application Server. Other examples include WebSphere Application Server Community Edition (IBM), Sybase Enterprise Application Server (Sybase Inc), WebLogic Server (BEA), JBoss (Red Hat), JRun (Adobe Systems), Apache Geronimo (Apache Software Foundation), Oracle OC4J (Oracle Corporation), Sun Java System Application Server (Sun Microsystems), and SAP Netweaver AS (ABAP/Java). Also, application servers may be provided in accordance with the .NET framework, including the Windows Communication Foundation, .NET Remoting, ADO.NET, and ASP.NET among several other components. For example, a Java Server Page (JSP) is a servlet that executes in a web container which is functionally equivalent to CGI scripts. JSPs can be used to create HTML pages by embedding references to the server logic within the page. The application servers may mainly serve web-based applications, while other servers can perform as session initiation protocol servers, for instance, or work with telephony networks. Specifications for enterprise application integration and service-oriented architecture can be designed to connect many different computer network elements. Such specifications include Business Application Programming Interface, Web Services Interoperability, and Java EE Connector Architecture. 
     Any patent, publication, or other disclosure material, in whole or in part, that is said to be incorporated by reference herein is incorporated herein only to the extent that the incorporated materials does not conflict with existing definitions, statements, or other disclosure material set forth in this disclosure. As such, and to the extent necessary, the disclosure as explicitly set forth herein supersedes any conflicting material incorporated herein by reference. Any material, or portion thereof, that is said to be incorporated by reference herein, but which conflicts with existing definitions, statements, or other disclosure material set forth herein will only be incorporated to the extent that no conflict arises between that incorporated material and the existing disclosure material. 
     While various example embodiments of the invention have been described herein, it should be apparent, however, that various modifications, alterations and adaptations to those embodiments may occur to persons skilled in the art with the attainment of some or all of the advantages of the present invention. The disclosed example embodiments are therefore intended to include all such modifications, alterations and adaptations without departing from the scope and spirit of the present invention as set forth in the appended claims.