Modern network computing allows great benefits by sharing information and computing resources. As an example, information is transmitted within networks between server computers and client computers in response to requests by the client computer's application.
Telnet provides an ability for client users to access host-based applications from the server. Interconnectivity is effectuated by telnet, even between different operating systems. At the application layer, telnet functions as a protocol to supply service use functions for remote operations. Telnet also functions at the session layer, providing dialog control, session administration, handling connection establishment, file transfer, and connection release. Further, telnet handles the presentation layer concern of translation.
Occasionally, errors occur in the execution of application instructions. Such errors can interfere with the performance of the application. Further, such errors can interfere with the sequential transfer of data between the server and the client. This is because, with some errors, from the point in time at which the error occurs until the error is corrected, further data sent by the server to the client will not be handled properly.
The data is not handled properly because it will be handled out of sequence, may lead to further errors and delays, with data backed up in queue, and/or data may be lost. Lost data may have to be retransmitted, which is time-consuming and wasteful of network resources. To prevent such improper handling, delays, and associated problems, it is desirable that servers be timely notified of the occurrence of application errors on the client.
Initially, error messages are handled like any other message; e.g., application errors are exchanged as normal Telnet messages. Upon discerning that a particular such message constitutes an error message, action may be taken thereon. However, no conventional mechanism exists to distinguish between error messages and regular data. Telnet thus conventionally views error messages in the same queue as other data.
With reference to Prior Art FIG. 1A conventional data flow 100A is depicted between a client and a server in which an error appears among the received data stacked at the client. Data queued by server 101 in a queue 103 is transmitted via telnet 105 from server 101 through a network 107 to telnet 109 for a client 111. Client application 115 requires the data from queue 111. An error 113 appears within the queue 111.
Referring to Prior Art FIG. 1B, a stack 121 of messages for use by application 115 contains usable data, as well as error message 123, by which application 115 is notified of the error 113 (Prior Art FIG. 1A). However, message stack 121 must be read completely, each message handled sequentially as it appears in stack 121, until error message 123 is reached.
Thus, application 115 must read all the data in stack 121 to discover and read error message 123, by which error 113 is discovered and appropriate action may be taken. This is inefficient and time-consuming. Moreover, server 101 may, since transmitting the data in queue 103, be compiling another corpus of data for transmission to client telnet 109 to continue a data flow 100B. This new data being queued in queue 103 may require processing of the data in queue 111 prior to its being sent to client 109.
Error 113 however forestalls complete processing of the data in queue 111 (Prior Art FIG. 1A). Thus, one of two possible deleterious effects can occur. Either the new data in queue 103 will be delayed at the server, or it will be sent before the data in queue 111 is fully processed, in which case it will be useless, and dropped. In fact, the previous data load must be re-sent without error beforehand. Thus, data will be lost, time will be wasted, and server and network resources will be taxed to correct the original error, as well as to ameliorate the compounded effects of re-sending replacement data for what is lost.
Applications thus have to parse each message, separate out any error messages, and then handle the error messages appropriately before taking appropriate ameliorative action. The application has to look at each and every message for error messages. However, this is time-consuming and resource-intensive. Also, it may not in some instances operate rapidly enough to prevent data backups, delays, and/or lost data.