The claimed subject matter relates to an architecture that can provide substantially lossless compression and subsequent decompression of messages at an application level. In particular, the architecture, in one aspect thereof, can receive a set of messages. When application data for received messages does not match stored message, the message can be stored to a buffer. In contrast, if application data matches that for a stored message, the received message can be discarded and a message count incremented. The compressed message pattern can include the stored message and the message count. Upon decompression, the number of messages received can be identified by the message count and the application data can be readily recreated for all messages by copying that data. Non-application data, such as time stamp information can be reconstructed based upon a buffer period, other timing offset data, or other data fields included in the message pattern.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is related to co-pending U.S. patent application Ser. No. 12/265,482 filed on Nov. 5, 2008, entitled, “AGGREGATE CONTROL FOR APPLICATION-LEVEL COMPRESSION.” The entirety of this application is incorporated herein by reference.

TECHNICAL FIELD

The present application relates generally to information compression techniques in a computer network, and more specifically to compressing and decompression of application instances such as periodic network messages.

BACKGROUND

In conventional systems, data compression or source coding is the process of encoding information using fewer bits than an uncompressed representation would use through use of specific encoding schemes. Compression is useful because it helps reduce the consumption of expensive resources, such as storage space or transmission bandwidth. On the downside, compressed data must be decompressed to be used, and this extra processing may be detrimental to some applications. This difficulty is especially true given that most compression or encoding algorithms today compress data at the bit level.

For example, conventional lossless compression algorithms seek to leverage statistical redundancies extant in the bit representations (e.g., 1's and 0's) that compose various types of data. Lossless compression schemes are reversible so that the original data can be reconstructed exactly as it existed prior to encoding. An example of lossless compression is ZIP file format, which is often employed for compressing documents or other data entities or data formats that require accurate recreation at the bit level. On the other hand, lossy encoding can provide greater compression ratios at the expense of some data loss. Generally, lossy compression is employed in connection with images, audio, or video files, sacrificing some degree of fidelity to attain a higher level of compression. Examples of lossy compression are MP3, MPEG, JPG formats. Both forms of compression have relatively rigid maximum compression ratios.

In the domain of computer network systems, bit-level compression of data can reduce bandwidth utilization, which can lessen the payload of traffic through potential resource bottlenecks. The trade-off is an increase in the required computational power to perform the compression/decompression algorithms, which commensurately increases the costs associated with various network equipment. In many instances, the cost-benefit analysis of this increased expense is not justified, especially when the occurrence of a resource bottleneck is a relatively low-probability event. For example, consider a network monitoring system (NMS) that tracks alarm messages from a network or a particular portion of a network.

Typically, the NMS will received alarm messages from network equipment (e.g., access multiplexers) when a fault condition arises with or is detected by the equipment. These fault conditions are often isolated events, and do not overly burden the NMS. However, in certain situations, “alarm storms” can arise. Alarm storms typically occur when many alarm messages are generated in a relatively short period of time, often due to a common or related set of events, e.g. due to malicious denial of service attacks or even due to natural forces such as weather. During alarm storms or other times of high alarm message input to a gateway of a NMS, the NMS is conventionally forced to shut down or discard much information that could be helpful to an upstream analysis system that might receive alarms from multiple NMS's to determine the nature of the problem. Accordingly, it would be beneficial to employ compression techniques to lessen the strain on the NMS during such times, yet bit-level compression techniques, with their limited compression ratios and higher additional costs do not appear adequate to address these or other suitable situations.

SUMMARY

The following presents a simplified summary of the claimed subject matter in order to provide a basic understanding of some aspects of the claimed subject matter. This summary is not an extensive overview of the claimed subject matter. It is intended to neither identify key or critical elements of the claimed subject matter nor delineate the scope of the claimed subject matter. Its sole purpose is to present some concepts of the claimed subject matter in a simplified form as a prelude to the more detailed description that is presented later.

The subject matter disclosed and claimed herein, in one aspect thereof, comprises an architecture that can facilitate substantially lossless compression of messages at an application level. Thus, while conventional compression schemes operate on bit level representations of data, the architecture can function on an entirely different data level, e.g. the application level, by compressing application instances such as messages. In accordance therewith and to other related ends, the architecture can receive a message that includes application data (e.g., certain application-specific data fields) and non-application data (e.g., time stamp information or the like).

The architecture can compress substantially any number of related incoming messages into a message pattern that, often, is approximately the same size as a single message. Hence, any given intermediary system that is subject to potential resource utilization bottlenecks, including but not limited to a network monitoring system (NMS), can implements the compression features at one edge of the potential bottleneck, and the decompression features at the other edge. Thus, bandwidth or other network resources can remain within acceptable levels even during periods of high usage, such as during alarm storms for instance. Moreover, because the compression employed is at the application level, actual traffic (e.g., the number of messages) can be reduced through the potential bottleneck. In contrast, bit-level compression would likely result in merely a reduction in the bit payload of each message rather than in the number of messages, is limited in compression ratio, and is likely more costly in terms necessary processing power.

The application-level compression can be accomplished by comparing the application data of received message to that for stored messages. If no match is found, then the received message can be stored to a buffer and a buffer timer can be started which will expire after a buffer period. On the other hand, if a match is found, then the received message includes identical application data as that for the stored message. Accordingly, a message count associated with the stored message can be incremented by 1, and the received message discarded. Upon expiration of the buffer period, the corresponding stored message along with the associated message count can be packaged into the message pattern and forwarded along.

At the decompression side, the architecture can received the message pattern, extract the stored message to create an original message. The original message can be copied to produce a number of duplicate messages based upon the message count. Since application data for the original message and all duplicates will be identical, only the non-application (e.g., time stamp information) data need be reconstituted. This can be achieved by adding a timing offset to the time stamp of the original message in a cumulative manner. The timing offset can be determined as a function of the message count and the buffer period, or in some other suitable manner.

The following description and the annexed drawings set forth in detail certain illustrative aspects of the claimed subject matter. These aspects are indicative, however, of but a few of the various ways in which the principles of the claimed subject matter may be employed and the claimed subject matter is intended to include all such aspects and their equivalents. Other advantages and distinguishing features of the claimed subject matter will become apparent from the following detailed description of the claimed subject matter when considered in conjunction with the drawings.

DETAILED DESCRIPTION

Referring now to the drawing, with reference initially toFIG. 1, system100that can provide substantially lossless compression of messages at an application level is depicted. In particular, rather than implementing bit-level compression algorithms or encoding to reduce the number of bits necessary for representing data, system100is directed toward reducing the number of application instances (e.g., messages), with little or no loss of application level data upon decompression. In accordance therewith, the claimed subject matter can, e.g., mitigate resource bottlenecks by compressing certain information at the application level before passing through potential resource bottlenecks.

In general, system100can include reception component102that can receive message104. Message104can include a wide variety of information, but will typically include at least application data and a time stamp, both of which are further discussed in connection withFIG. 2. In an aspect of the claimed subject matter, message104can be a network monitoring system (NMS) alarm message that can, e.g. indicate a failure or malfunction condition for a network resource. Thus, to provide concrete illustrations, message104is generally described herein in the context of an NMS alarm message, however, it should be appreciated and understood that message104can relate to other applications as well.

While still referring toFIG. 1, but turning also toFIG. 2, exemplary message104is illustrated as a NMS alarm message. As indicated supra, message104can include application data that can relate to a particular context or application, an example of which is provided at reference numeral202. In this case, in the context of a NMS alarm message, application data202of message104can include a number of data fields relating to network monitoring. For example, application data202can include alarm severity204that can indicate, e.g., a predefined level of importance for the NMS alarm message104. A name or serial number of the equipment or device that is subject to a failure condition and/or is reporting the failure condition can also be included in NMS message104as denoted by reference numeral206. Additionally, failure type208(e.g., failed hardware, a cut line, a loss of signal . . . ) can also be included in alarm message104. Hierarchy level210of the reporting device or equipment can be included in NMS message104as well, which is further detailed infra. Naturally, other suitable fields, although not expressly depicted, can exist as application data202.

In addition to example application data202, message104can also include time stamp212. Time stamp212will typically include a time value representing a date and time when message104is generated or transmitted by the disparate equipment or device. However, in some cases, time stamp212can be a time in which message104is received by reception component102. Appreciably, other fields can exist apart from time stamp212and those included in application data202, which is detailed further herein.

Continuing the description ofFIG. 1, system100can also include compression component106that can examine stored messages110included in buffer108. For instance, compression component106can compare application data202from message104to corresponding application data contained in stored messages110. When compression component106does not find matching application data202among stored data110, then compression component106can store message104to buffer108as stored message110. On the other hand, when compression component106finds matching application data202among stored messages110, then it can be assumed that message104is a duplicate message of a previously received message104. For example, based upon the previously introduced scenario in which message104is a NMS alarm message, when resources fail in a network, it is common for equipment related to the failure to transmit NMS alarm messages at discrete intervals, e.g., an alarm every 30 seconds or the like. Thus, the first NMS alarm message will generally be identical to a duplicate alarm message (e.g., one transmitted 30 seconds later) in terms of application data202, differing only in the value of time stamp212or other non-application data fields (e.g. fields not used for matching purposes). Thus, by contrast, application data202can be thought of as those data fields that are identical among all messages104for a particular application.

Accordingly, when application data202matches that for a stored message110, compression component106can increment a message count associated with the matching stored message110rather than saving the received message104to buffer108. Later, for instance during a decompression stage, the message count can be indicative of the number of messages104that were received, all with substantially identical application data202. Thus, all received messages104can be recreated based upon a single message104by, e.g., producing copies of application data202. While other data fields, such as time stamp212(or other non-application data fields) are not identical for duplicate messages, in many cases, even this information can be accurately recreated as well, as further described herein.

Hence, when compression component106can detect matching application data202already included in buffer108, the message count can be incremented and message104simply discarded. The described mechanism for compression at the application level can potentially reduce hundreds of application-based messages104into one or more data entity that is approximately the size of a single message104, all with little or no loss of information, without employing slow and resource-intensive bit-level compression, and without the inherent upper bound on data compression ratios that limit bit-level compression efficiency. As an example case, messages104can be compressed before a potential network resource bottleneck, transferred through the potential bottleneck in compressed format, and then decompressed once beyond the potential bottleneck. For instance, referring again to the NMS, compression component106as well as other components included in system100can be implemented at a gateway that receives incoming messages from network equipment such as, e.g. access multiplexers.

These or other aspects can be quite beneficial to, e.g., a NMS during “alarm storms” that can overload the monitoring resources or in some cases shut down all processing altogether. Such alarm storms occur for a variety of reasons ranging from malicious denial of service attacks to resource failure due to adverse weather conditions or natural disasters; and conventionally result in a shutdown or malfunction in the NMS or, at a minimum, a loss of information to upstream network analysis systems that typically would utilize the lost information to accurately determine the nature of the failures or other network conditions or troubleshooting endeavors. Yet, by employing the claimed application level compression, certain vagaries associated with alarm storms or other resource bottlenecks can be mitigated.

Still referring toFIG. 1, system100can further include scheduler component112that can monitor buffer timer114and that can forward message pattern116upon expiration of a buffer period. Message pattern116can include, inter alia, stored message110and the message count for the stored message110, wherein stored message110is a received message104that is stored to buffer108. In addition, scheduler component112can initiate buffer timer114when compression component106stores message104to buffer108(as stored message110). Thus, buffer timer114can begin timing at the point when a stored message110is input to buffer108. Once buffer timer114counts for a period equal to the buffer period, then scheduler component112can remove stored message110from buffer108, and forward message pattern116(which can include stored message110). Appreciably, each stored message110can be associated with a unique buffer timer114or, in some cases, to a unique buffer108or portion of buffer108.

As can be readily appreciated, any received message104with identical application data202to that of a stored message110can increment the message count for that stored message110. Thus, the message count will typically accrue while stored message110remains in buffer108, an amount of time defined by the buffer period. To provide a concrete illustration of the above, consider the following scenario.

Consider a NMS with the buffer period set to 5 minutes. Thus, incoming alarm messages104that are unique can be buffered as stored message110for 5 minutes. During the 5 minute buffer time, any repeated alarm messages104(e.g. messages with matching application data202) can be discarded but with the message count associated with the stored message incremented by 1. If it is further assumed, as an example, that the network device transmitting the incoming alarm messages104does so at 30 second intervals, then upon expiration of the 5 minute buffer period, the message count for the described alarm will be incremented to 10 (e.g., 10 messages received from the device in the 5 minute buffer period). Appreciably, by dividing the buffer period by the message count, an interval for the alarm messages can be thus determined. For instance, based upon the above scenario, the 5 minute buffer timer divided by a message count of 10=30 second interval. By determining the interval, time stamp212information can be recreated based upon the time stamp212included in stored message110, even though that information for 9 of the messages need not be explicitly included in message pattern116. Accordingly, substantially all information included in those 10 messages104, can be compressed into a single message pattern116that includes stored message110and the message count, and is therefore approximately the same size as only one message104.

In an aspect of the disclosed subject matter, compression component106can append a count field to stored message110, and can populate the count field with the message count for that stored message110. Accordingly, message pattern116can be comprised of a single data entity rather than a combination of two or more data entities. This concept, as well as numerous additional concepts, is depicted with reference toFIG. 3.

Turning now toFIG. 3, example pattern116that comprises a stored message, a message count, and various other optional fields is illustrated. It should be understood that all or a portion of the fields detailed herein or otherwise suitable for inclusion can be included in stored message110as well. In such a case, compression component106can append the fields to stored message110. Otherwise, these additional fields can be appended to a data structure denoted as pattern116. Accordingly, as detailed supra, application data202and time stamp212that are included in stored message110can be included in pattern116, as pattern116comprises stored message110. Likewise, whether embedded in stored message110or kept distinct, message pattern116can also include message count302, as discussed supra.

In addition, compression component106can append buffer time field304to stored message110(or message pattern116), and can populate buffer time field304with the buffer period. Hence, the buffer period can be included in the information forwarded by scheduling component112. However, it should be appreciated that the buffer period can be based upon a default time (e.g., 5 minutes or some other period), or acquired or set in some other manner. Thus, buffer time field304is generally an optional field and need not necessarily be expressly included in message pattern116.

Furthermore, compression component106can append repeat time field306and can populate repeat time field306with a time value that represents a duplicate message interval determined by subtracting a stored time stamp212of stored message110included in buffer108from a time stamp212of a subsequently received message104. In many situations, such as in the scenarios detailed supra, incoming messages104will be transmitted (e.g., from network equipment) at set intervals. By determining the interval based upon actual time stamps212, it is therefore not necessary to determine this value by other means. Accordingly, example message pattern116need only include buffer time field304or repeat time filed306, but not both.

Additionally or alternatively, compression component106can append end time field308to message pattern116or stored message110. End time field308can be populated with a last message time stamp included in a last message. The last message can, e.g., represent a final duplicate message received prior to expiration of the buffer period. Hence, again returning to the previously introduced example in which 10 messages104are received within the 5 minute buffer period, a time stamp for each message104received can be input to end time field308, with each new entry replacing the previous entry. Thus, upon input of the time stamp for the 10th or last message received, that final time value can be saved.

Generally, since buffer timer114begins when the first message is received, and since each message is transmitted at 30 second intervals, the 10th message104received will likely include a time stamp212that is 5 minutes later than the time stamp212for stored message110. However, in the event that buffer timer114is not a multiple of the interval, or even when slight delays in the last message104might cause that message to arrive slightly later than expiration of the buffer period, calculating the interval based upon end time field308can be more accurate. Therefore, it should be appreciated that end time field308can be utilized instead of either buffer time field304or repeat time filed306. It should also be appreciated that other aspects of lossless compression are also contemplated. For example, each time stamp212from duplicate messages can be included in message pattern116along with the message count. In such a case, message pattern116can be interpreted appropriately by examining the message count, with the number of recreated fields for each message being the total number of additional fields divided by the message count. Moreover, such a technique can allow the compression/decompression of substantially any type of non-application data202(e.g., types other than time stamp information), at the cost of slightly increasing the payload of message pattern116.

Turning back toFIG. 1, it should be appreciated that system100can facilitate compression at an application-level of messages104in the manner described herein. In more specific contexts, such as when employed by NMS systems as discussed supra, system100can facilitate further compression. For example, given certain network hierarchy information, system100can be utilized to determine or infer likely messages104that will or should arise based upon examination of a particular message104. In particular, compression component106can compare a NMS alarm message to a hierarchical network topology to identify a high-level resource failure. Such can be accomplished by examination of, e.g. hierarchy level210or by another means (e.g., by equipment name/SN206).

Appreciably, when a particular resource fails, all dependent (e.g. lower level resources that depend upon the failed resource) will also like generate failure alarms. For instance, suppose a NMS alarm is received relating to a controller card that has failed. Accordingly, it can be determined or inferred that all ports or services that rely upon that card have or will also fail. Thus, compression component106can intelligently facilitate further application-level compression by generating a set of alarm messages for a lower hierarchical network resource that is dependent upon the high-level resource. These messages can be compressed in the same manner as those received, and can be employed to aid an upstream analysis system in determining the extent and nature of the fault. In addition, such features can forego the compression stage entirely and be employed at the decompression stage further enhance the efficiency.

To aid in these and other related endeavors, system100can further include or be operatively connected to data store118. Data store118is intended to be a repository of all or portions of data, data sets, or information described herein or otherwise suitable for use with the claimed subject matter, and can include or be operatively coupled to buffer108. Data store118can be centralized, either remotely or locally cached, or distributed, potentially across multiple devices and/or schemas. Furthermore, data store118can be embodied as substantially any type of memory, including but not limited to volatile or non-volatile, sequential access, structured access, or random access and so on. It should be understood that all or portions of data store118can be included in system100, or can reside in part or entirely remotely from system100.

Turning now toFIG. 4, system400that can provide substantially lossless decompression of compressed messages at an application level is depicted. In general, system400can include receiving component402that can receive message pattern116. Message pattern116can include a message (e.g., message104or stored message110) and the message count associated therewith, both as substantially described supra. Accordingly, the message portion of message pattern116can include application data202and time stamp212, as discussed in connection withFIG. 2. Moreover, the message count can be embedded in the received message or in a disparate portion of message pattern116. In addition, message pattern116can include various additional fields depending upon a particular implementation, as is depicted in connection withFIG. 3.

Furthermore, system400can also include data store118as well as decompression component404that can extract application data202and time stamp212from message pattern116. These extracted elements can then be embedded into a separate data structure to produce original message406. Thus, original message406can be substantially identical to an initial incoming message104that is stored to buffer108as stored message110. In addition, decompression component404can produce a number of duplicate messages408, wherein the number of duplicate messages408generated can be based upon the message count. For instance, if the message count is 10, then decompression component can produce the original message406and 9 duplicate messages408. Each duplicate message408can be created by copying application data202of original message406, since application data202is typically identical for a given message104that is matched by compression component106ofFIG. 1.

Accordingly, each duplicate message408will differ only in non-application data, which in this case are the values of associated time stamps212. It should be underscored yet again that other non-application data can exist, which can be recreated by various other means. However, in this case, in order to fully decompress message pattern116, the time stamp information for each duplicate message408must be recreated. Such ends can be accomplished by decompression component404by populating a time stamp field for each duplicate message408with a value that can be derived by cumulatively adding a timing offset to the time stamp of original message406.

Typically, the timing offset is intended to represent the interval in which messages104were received. Thus, if each related message104is received at 30 second intervals, then message pattern116will be encoded in a manner to allow decompression component404to translate or discover such information. In one aspect, decompression component404can determine the timing offset as a function of the buffer period detailed in connection with buffer108ofFIG. 1. For example, given a buffer period of 5 minutes, a message count of 10 would indicate that the interval is 30 seconds. Thus, decompression component404can add 30 seconds to the time stamp of original message406and populate the time stamp field of the first duplicate message408with that value. 60 seconds (e.g., timing offset multiplied by 2) can be added to the time stamp of original message406to yield the time stamp for the second duplicate408, and so on.

Appreciably, the buffer period can be a predefined value known to or discoverable by decompression component404. Additionally or alternatively, the buffer period can be included in message pattern116, such as in buffer time field304. More generally, decompression component404can determine the timing offset as a function of the message count and a value included in one or more data fields of message pattern116. The one or more data fields can include, e.g. buffer time field304, as already mentioned; repeat time field306, which relates to an interval measured by subtracting time stamp values from related incoming message104; end time field308, which relates to a difference between a first and last related message received during the buffer period; or by another suitable field or input.

Moreover, decompression component404can intelligently generating a set of alarm messages that do not rely upon processing at the compression stage. For example, decompression component404can be aware of various features of network topology. Thus, should a higher-level resource fail, then predictions or inferences relating to a lower hierarchical network resource that is dependent upon that higher-level resource can be made. Accordingly, decompression component create original and/or duplicate message406,408by copying the time stamp information from messages originating from higher-level resources and fill in suitable application data based upon, e.g., a hierarchical network topology map. Such messages can be employed to aid an upstream analysis system in determining the extent and nature of the fault.

In an aspect of the disclosed subject matter, system400can also include transmission component410that can propagate original message406as well as all duplicate messages408to a disparate system. For example, returning once more to the NMS scenario, the subject matter disclosed herein can avoid potential bottlenecks associated with alarm storms or other resource-intensive events by compressing the alarm messages as discussed above, passing that compressed data pattern through the potential bottleneck, and then decompressing the pattern to yield substantially identical messages. Upon completion of the decompression, all messages can be forwarded, e.g. to an upstream analysis system that can utilize the information contained therein to address the situation. It should be appreciated, that transmission component410can transmit original message406first, then simulate the interval of the arriving messages104(e.g., every 30 seconds) by dispatching a duplicate message408every 30 seconds or the value of the interval otherwise determined or inferred.

It is readily understood that in such a case, the disparate system will receive each decompressed message as though directly from the source of the message (e.g., failing network hardware), but with an offset equal to the buffer period (e.g., 5 minutes). Alternatively, transmission component410can transmit original message406and all duplicate messages408substantially simultaneously. Given that the time stamp information relating to the message origin has been accurately recreated during decompression, it often will not matter when the disparate system receives the messages in terms of processing or analysis. In this latter case, it should be appreciated that the delay due to the buffer period can be effectively reduced, given that the last duplicate message408will include a time stamp very similar to the time in which the disparate system receives that message, with a difference limited substantially to the propagation delay between the two and the processing time to compress/decompress the messages.

Turning now toFIG. 5, system500that can provide or aid in various inferences is illustrated. Typically, system500can include compression component106that can compare received messages and increment a message count when application data202for the compared messages matches in order to facilitate creation of message pattern116, as substantially described supra. Furthermore, system500can also include decompression component404that can extract application data from message pattern116and recreate non-application data for duplicate messages based upon information included in message pattern116, also as detailed supra.

In addition, system500can also include intelligence component502that can provide for or aid in various inferences or determinations. It is to be appreciated that intelligence component502can be operatively coupled to all or some of the aforementioned components, e.g.106and404. Additionally or alternatively, all or portions of intelligence component502can be included in one or more components described herein. Moreover, intelligence component502will typically have access to all or portions of data sets described herein, such as access to data store118, and can furthermore utilize previously determined or inferred data.

For example, intelligence component502can aid compression component106or decompression component404by intelligently determining or inferring a set of alarm messages related to a lower-level device on a hierarchical network map. For example, when a message relating to a higher-level network device is received, it can be determined or inferred that a dependent lower-level network device will also be subject to failure conditions. Appropriate messages relating to the lower-level device can be generated even without receiving such messages either at the compression stage or decompression stage.

In accordance therewith, in order to provide for or aid in the numerous inferences described herein or otherwise suitable, intelligence component502can examine the entirety or a subset of the data available and can provide for reasoning about or infer states of the system, environment, and/or user from a set of observations as captured via events and/or data. Inference can be employed to identify a specific context or action, or can generate a probability distribution over states, for example. The inference can be probabilistic—that is, the computation of a probability distribution over states of interest based on a consideration of data and events. Inference can also refer to techniques employed for composing higher-level events from a set of events and/or data.

Such inference can result in the construction of new events or actions from a set of observed events and/or stored event data, whether or not the events are correlated in close temporal proximity, and whether the events and data come from one or several event and data sources. Various classification (explicitly and/or implicitly trained) schemes and/or systems (e.g. support vector machines, neural networks, expert systems, Bayesian belief networks, fuzzy logic, data fusion engines . . . ) can be employed in connection with performing automatic and/or inferred action in connection with the claimed subject matter.

Turning now toFIG. 6, exemplary method600for providing application-level compression of messages in a substantially lossless manner is depicted. In general, at reference number602, a message including at least application data and a time stamp can be received. As one example, the message can be in the form of a NMS alarm message from network resource indicating a fault condition is present or otherwise detected. The NMS alarm message can include the time stamp (or other non-application data) indicating when the messages was generated by the disparate network resource as well as a number of additional fields relating to the nature of the message and the identity of the resource transmitting the data. These additional fields typically constitute the application data. However, it should be appreciated that beyond NMS alarm messages, other messages or application-level data entities can be received with application data and non-application data defined differently.

At reference numeral604, the application data included in the message can be compared to a set of stored messages for identifying a matching message. The stored messages can exist in one or more buffers, potentially having a unique buffer for each stored message. If a matching stored message is identified (e.g., the application data of the incoming message is equivalent to the application data for the matching stored message), then at reference numeral606, a message count associated with the matching message can be incremented. At reference numeral608, a message pattern including the matching message and the message count can be constructed and forwarded when a buffer timer expires. In particular, when the buffer timer for the matching stored message expires, the associated stored message can be forwarded, typically through a path subject to a potential resource bottleneck to a decompression system at the other edge of the potential resource bottleneck.

Turning now toFIG. 7, exemplary method700for providing additional features associated with application-level compression in a substantially lossless manner is illustrated. According to the diagram, at reference numeral702, the incoming message received at reference numeral602can be deleted when the matching stored message is incremented (e.g., at reference numeral606). Hence, once a matching message is identified and the associated message count incremented, then the received message can be simply discarded.

However, at reference numeral704, when no matching message is identified, then the received message can be stored to the buffer. Once stored to the buffer, at reference numeral706, the buffer timer discussed in connection with reference numeral608can be activated and/or initiated. In other words, if a match for the incoming message is found, then the message count for the matching message can be incremented and the incoming message disposed of. When no match is found, the incoming message is saved to the buffer with the buffer timer activated for the duration of the buffer period.

Next to be described, at reference numeral708, the message count can be appended to the matching stored message prior to forwarding the message pattern (e.g., detailed at e.g.608). Thus, updating the message count can entail updates to a particular data field included in the stored message. At reference numeral710, one or more timing offset fields can be appended to the matching message prior to forwarding the message pattern. For example, the one or more timing offset fields can relate to the buffer period, a repeat time between related messages determined by the difference between time stamps, an end time that records a time stamp for the last message effectuating a message count increment prior to expiration of the buffer timer, or some other offset information.

With reference nowFIG. 8, exemplary method800for providing application-level decompression of messages in a substantially lossless manner is provided. In accordance therewith, at reference numeral802, the message pattern forwarded at reference numeral608can be received. Upon receipt of the message pattern, at reference numeral804, an original message can be recreated based upon the application data and the time stamp extracted from the matching message included in the message pattern.

Given that it is known that application data included in the original message will be identical to all related messages discarded at reference numeral702, thus, these messages can be reconstituted based upon information included in the message pattern. In particular, at reference numeral806, duplicate messages can be constructed by copying the original message (or at least the application data portion of the original message) a particular number of times indicated by the message count. Thus, the message count included in the message pattern can indicate the number of duplicates to construct.

At this point, the duplicates will be identical to the original message, at least insofar as application data is concerned. However, non-application data must be recreated, in particular, the time stamp information associated with the messages deleted at reference numeral702. Therefore, at reference numeral808, the time stamp for each of the duplicate messages can be updated by adding a timing offset to a value of the time stamp of the original message. It should be appreciated that the timing offset can be derived from a known buffer period divided by the message count. Additionally or alternatively, the timing offset can be included in the message pattern as one or more fields, as discussed in connection with reference numeral710supra. For instance, the timing offset can be cumulatively added to each successive duplicate message.

Turning now toFIG. 9, exemplary method900for providing additional features associated with application-level decompression in a substantially lossless manner is depicted. At reference numeral902, the timing offset employed at reference numeral808is determined based upon a quotient of the buffer period over the message count. Similarly, at reference numeral904, the timing offset is determined as a function of the message count and a value included in a data field of the matching message (or the message pattern), wherein the value relates to at least one of the buffer timer, a repeat interval, or a last message time, which was also introduced supra in connection with reference numeral808. At reference numeral906, the original message and each duplicate message constructed from the message pattern can be transmitted to a disparate system, such as an upstream analysis system.

Referring now toFIG. 10, there is illustrated a block diagram of an exemplary computer system operable to execute the disclosed architecture. In order to provide additional context for various aspects of the claimed subject matter,FIG. 10and the following discussion are intended to provide a brief, general description of a suitable computing environment1000in which the various aspects of the claimed subject matter can be implemented. Additionally, while the claimed subject matter described above may be suitable for application in the general context of computer-executable instructions that may run on one or more computers, those skilled in the art will recognize that the claimed subject matter also can be implemented in combination with other program modules and/or as a combination of hardware and software.

Continuing to referenceFIG. 10, the exemplary environment1000for implementing various aspects of the claimed subject matter includes a computer1002, the computer1002including a processing unit1004, a system memory1006and a system bus1008. The system bus1008couples to system components including, but not limited to, the system memory1006to the processing unit1004. The processing unit1004can be any of various commercially available processors. Dual microprocessors and other multi-processor architectures may also be employed as the processing unit1004.

A monitor1044or other type of display device is also connected to the system bus1008via an interface, such as a video adapter1046. In addition to the monitor1044, a computer typically includes other peripheral output devices (not shown), such as speakers, printers, etc.

When used in a LAN networking environment, the computer1002is connected to the local network1052through a wired and/or wireless communication network interface or adapter1056. The adapter1056may facilitate wired or wireless communication to the LAN1052, which may also include a wireless access point disposed thereon for communicating with the wireless adapter1056.

When used in a WAN networking environment, the computer1002can include a modem1058, or is connected to a communications server on the WAN1054, or has other means for establishing communications over the WAN1054, such as by way of the Internet. The modem1058, which can be internal or external and a wired or wireless device, is connected to the system bus1008via the serial port interface1042. In a networked environment, program modules depicted relative to the computer1002, or portions thereof, can be stored in the remote memory/storage device1050. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers can be used.

Referring now toFIG. 11, there is illustrated a schematic block diagram of an exemplary computer compilation system operable to execute the disclosed architecture. The system1100includes one or more client(s)1102. The client(s)1102can be hardware and/or software (e.g., threads, processes, computing devices). The client(s)1102can house cookie(s) and/or associated contextual information by employing the claimed subject matter, for example.

The system1100also includes one or more server(s)1104. The server(s)1104can also be hardware and/or software (e.g., threads, processes, computing devices). The servers1104can house threads to perform transformations by employing the claimed subject matter, for example. One possible communication between a client1102and a server1104can be in the form of a data packet adapted to be transmitted between two or more computer processes. The data packet may include a cookie and/or associated contextual information, for example. The system1100includes a communication framework1106(e.g., a global communication network such as the Internet) that can be employed to facilitate communications between the client(s)1102and the server(s)1104.

Communications can be facilitated via a wired (including optical fiber) and/or wireless technology. The client(s)1102are operatively connected to one or more client data store(s)1108that can be employed to store information local to the client(s)1102(e.g., cookie(s) and/or associated contextual information). Similarly, the server(s)1104are operatively connected to one or more server data store(s)1110that can be employed to store information local to the servers1104.

What has been described above includes examples of the various embodiments. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the embodiments, but one of ordinary skill in the art may recognize that many further combinations and permutations are possible. Accordingly, the detailed description is intended to embrace all such alterations, modifications, and variations that fall within the spirit and scope of the appended claims.