Transcription
AbstractRemote Top (RTOP) is a protocol providing a near real-time system and process information for anynumber of host machines on a TCP/IP network. RTOP provides all information from each host machinesimilar to that of the UNIX Top program, also allowing for remote administration of the client hostprocesses from a system standpoint.IntroductionRTOP consists of both a server process, periodically polling registered host machines for current processinformation and storing registered machine location information, and a client process running on clienthost machines, which receive polling requests from the server as well as send registration information tothe server.A network will have one or more designated RTOP “servers” which will receive registration requestsalong with remote process information that it will periodically request from registered machines, and“clients” which will provide initial registration to be stored on the server, along with process informationwhen requested.Any “client” machine on a network shall only be registered with one “server”. The server with which theclient is registered should be stored on this client, and the client should respond to any requests forprocess information from servers with which it is not registered with an error message.Goals:The general goals of RTOP are as follows. RTOP is to provide an accurate method for the remote view of all registered client machines’process info. RTOP polling frequencies must be frequent enough to provide a near real-timepicture of the state of the network machines, but not so frequent as to affect either the server,the client or the TCP/IP network due to the traffic incurred.Once a client machine has been registered on a server and the server information stored on theclient machine, the client’s interaction with the server will be involuntary and invisible to theclient machine, save the lightweight process used to respond to polls, along with responding tokill requests sent from the client machine.To facilitate the proximity to real-time, the server should be capable of sending out requests andreceiving response information as it arrives, no matter the concurrency of the multipleresponses or the requests.
Each round of requests will be accompanied by a poll ID so as to maintain a connection betweenthe requests and the responses. In this manner, the server can “age” the responses, and provideinformation relating to non-responsive clients (or machines that have been shut down).No ramifications will result from a registered client not being polled in the standard pollingperiod, i.e. the RTOP server going down for any reason.No ramifications on the server will be experienced for any non-responsive client other than tohave stale or missing information for that client.Client registration will be understood to be permanent with the server. Clients will not be forcedto un-register with the server, rather the clients will be deleted from the server side if the serverno longer wishes to poll the client.Client information must be stored in a persistent manner on the server so not as to force clientsto re-register after a server re-entering service after a restart. Similarly, the server with whichthe client is registered will be stored on the client (to preserve the client-server relationship) in apersistent manner so as not to refuse messages from the server when they arrive.Protocol SummaryFigure 1 gives the format of a RTOP message and table 1 describes each of the fields in the RTOPmessage. The numbers in parentheses indicate the size of each field in octets. The names for the fieldsgiven in the figure will be used throughout this document to refer to the fields in RTOP messages.{INSERT A TABLE OF THE MESSAGE LAYOUT}Figure 1: Format of a RTOP message{INSERT DETAILED DESCRIPTIONS OF ALL OF THE FIELDS}Server ImplementationThe only requirement of the protocol itself on the server side is that the server store the clientregistration (i.e. a unique identifier for each machine registered, along with IP address information) in apersistent manner, and that it poll the client machines at a specified periodicity determined by bestpractices and also stored on the server in some persistent manner that allows for the closestapproximation of real-time knowledge of client machine resources without taxing the network or anyinvolved machines in too large a way.The spirit of this document is to provide a useful protocol allowing for a user interface to display in somemanner the process information for the entire network. It is not a requirement of the protocolnecessarily, but the interface is envisioned by the author of this document to be not too dissimilar to theUNIX Top program output. That user interface, however, is the choice of the implementing softwareengineer and not a directive of this document.
Client ImplementationThe client implementation of the protocol directs that the client have some method of sending aregistration request (manually input preferably by an authorized user such as machine-level or networklevel administrator) to the server, and the storage of the server information in a persistent manner oncea successful registration has occurred.The only other requirement of the protocol is that a process run on the client that waits for polls fromthe client and respond to them with the current process usage information as long as the serverrequesting information is the one with which the client has stored as it’s registered server.Messages exchanged between the client and the server RTOPREG – The client-initiated request for registration of the RTOP client on a RTOP serverlocated on the network.RTOPREGACK – The RTOP server response to a successful registration, indicating that the RTOPclient information has been stored persistently on the server and that the client will be polled bythe server at some pointRTOPREGERR – An error message returned by the server for any failure of a client to appearunique. This would possibly be returned if the server has more than one client MAC addressregistered for the same IP address. This failure means that the duplicate client must first be unregistered on the server-side prior to the completion of successful registration.RTOPPOLL – The RTOP server-initiated poll for process information of any of the registeredRTOP clients. Includes a unique poll identifier, allowing the server to determine the age ofresponses in the case of overlapping client responses.RTOPRESPONSE – The RTOP client response to the RTOPPOLL request. Includes all currentprocess and system resource information for aggregation on the server.RTOPPOLLERR – The response from a RTOP client if the RTOP server that sent the RTOPPOLLrequest was not the correctly registered server according to the persistent storage informationon the client. The best course of action, although not required by this protocol, would be todelete the client from the table of stored clients on the RTOP server after a certain number ofthese error responses consecutively by the same client.RTOPRESPONSEERR – The response from a RTOP server back to a RTOP client that has sent aRTOPRESPONSE to a server, even though the server may not have the client registered in itspersistent storage. Possible causes: server or client general malfunction, IP address change, etc;client being deleted from server table between request and response, etc. Not required, butrecommended by this protocol, would be to delete the server registration from the client if thishappens after a certain number of consecutive RTOPRESPONSEERR messages are received.
RTOPKILLREQUEST – The request from the RTOP server to kill any client process by PID for thatprocess. This capability is allowed for in the design of the protocol, but the implementation of it,including the security necessary to allow server access to kill client processes, is theresponsibility of the implementer.RTOPKILLRESPONSE – The RTOP client response to the server request for a kill. Can be positive,as in the process was successfully killed, neutral, as in the kill is delayed, or negative, as in thekill was not successful.RTOPKILLERR – The RTOP client response to the server request for a kill if that server does notmatch the server registered in persistent storage for the client, or if the implementer of thisprotocol has determined programmatically that the server does not have access to kill processeson client machines due to security issues.Client-server interaction - client registrationThe following is a summary of the messages exchanged between the client and server for registering theclient on the server so that the server may add it to its polling table storage. The table in figure 2 belowdescribes the message fields exchanged in detail and the timing diagram in figure 3 describes the timingof the exchange of the messages.1. The RTOP client broadcasts a RTOPREG message to a RTOP server. This message is initiated by auser manually, knowing the IP address of the RTOP server, via some user interface.2. The RTOP server, if it is running, receives thee RTOPREG and responds with a RTOPREGACKmessage. The server adds the client to persistent storage as a client that will be polledperiodically.3. The RTOP client receives the RTOPREGACK message, at which point the client will store theserver information in persistent storage. The server will now be accepted as approved for theclient to respond to polling, described in the next section.{INSERT TABLE DESCRIBING MESSAGE FIELDS}Figure 2: Description of fields in the RTOP message.{INSERT DIAGRAM OF MESSAGE TIMING FOR CLIENT REGISTRATION}Figure 3: Timing diagram for client registrationClient – server interaction: Server polling.
The following is a summary of the messages exchanged between the client and the server for the serverto poll and receive process information from the client. The timing diagram in figure 4 describes thetiming of the messages that are sent and received for this process.1. After an idle period specified by server-stored configuration information, the server sends aRTOPPOLL message to each client registered and stored on the server.2. The RTOPPOLL message is received by each client, and it uses its process information to sendback a RTOPRESPONSE message containing all of this information for aggregation on the server.
Once a client machine has been registered on a server and the server information stored on the client machine, the client's interaction with the server will be involuntary and invisible to the client machine, save the lightweight process used to respond to polls, along with responding to kill requests sent from the client machine.
