External javascript libraries, decompression, ebcdic


#1

Hi,
several questions in one… I need to develop a specialised adapter and it involves decompressing a zlib compressed payload, working with the tcp header and ebcdic strings.

  1. What would be the best approach for decompression?
  2. I have located an open source javascript library that can deflate zlib. What is a practice for adding an external javascript library to the appliance and accessing it from the trigger? Is it possible? Can I get access to the appliance OS?
  3. similar with ebcdic, is any library available on ExtraHop and how to use it from a trigger?

#2

There aren’t ExtraHop-provided JS libraries for zlib or ebcdic. To add external JS libraries to your trigger, copy/paste their source code (or minified source) into that trigger’s source code.


#3

Howdy, thanks for previous reply. I have integrated several libraries to my trigger. Quick question, what solution would you recommend to make sure that library is not parsed each time trigger fires, one in the example below (standard in javascript libraries) or caching. I experimented with cache() to cache individual library functions and it should work too. Much prefer the 1st approach…

// EBCDIC library
(function (encodeLib) {
     'use strict';
     if (encodeLib.EBCDIC)   // this makes sure that lib function executes only in the first trigger
          return;
	...
     encodeLib.EBCDIC = {
         fromEBCDIC: decode,
	  toEBCDIC: encode,
		fromEBCDICstr: decodeASCII,
		VERSION: version
	};
	...
})(this);

caching approach:

function StringsFn() {
    return {
        "times1": function (a) {return a;},
        "times2": function (a) {return a+a;},
        "times3": function (a) {return a+a+a;}
    };
}
var libF = cache('libF', StringFn);
idd = libF['times3']('tx-');

#4

The ExtraHop does not preserve state across trigger executions, and you should not use this in our triggers. The caching approach is more idiomatic for our system. You could choose to cache the EBCDIC library by returning the object you’re assigning to encodeLib, and then caching that.

Have you run into performance problems including the library without caching? Optimizations such as using cache are easy to add later, so we recommend starting with the simplest approach that works and then progressively improving performance as-needed.


#5

Ted, thanks. I have not yet tested this approach in production so I can’t comment on the performance. What I can say is that the approach seems to work, i.e. the functional expression defined library code is parsed only once at the first trigger execution and never after that. It is actually behaving so well that it is hard to redefine the library - I usually comment out the “if ( …” test and next trigger execution redefines the lib. Re-saving the trigger, disabling/enabling it does not do much, I think even deleting and re-defining the trigger did not work but I have not spent much time on this (the 30s timing may be the issue here, I usually do that faster :slight_smile: ).

I tried this approach as my understanding how the trigger mechanism is implemented in ExtraHop is nonexistent. I am assuming that there is some server implementing javascript engine but the details escape me so it has been mostly trial and error for me.

Back to your comment. I hear what you say about the state in triggers however could we rely on the javascript engine here? The approach above seems to suport it; or are you saying that it is only a local behavior that we could not rely on? BTW, I think that the “this” is used in my code only to self-execute the functional expression and as such is not used to store or access the “state”.

How is “cache” implemented? Where I could find more on the trigger mechanism architecture?

will try to put my object to cache, should not be too much problem.

Thanks for your time, appreciate your replies! A.


#6

ExtraHop embeds a JavaScript runtime to execute triggers.

From a black-box point of view, triggers run as global/free functions. Just like you shouldn’t rely on this in functions that aren’t methods, you shouldn’t rely on it in triggers. Personally, I put "use strict"; at the top of my triggers to prevent any mishaps on this front.

We don’t have a public document on the architecture around triggers, as we can (and do) change the implementation between versions to improve performance. However, you can find documentation on the function here, which covers the supported usages.


#7

Ted, thanks. Yes, I have seen API doc.

Modified the library, works OK.

function eLib() {
    'use strict';
    ...
    var EBCDIC = {
            fromEBCDIC: decode,
            toEBCDIC: encode,
            fromEBCDICstr: decodeASCII,
            VERSION: version
    };
    if (typeof Object.defineProperty === 'function') {
            var noEnum = function (v) {
                    return {
                            value: v,
                            enumerable: false,
                            writable: true,
                            configurable: true
                    };
            };
            EBCDIC.extendString = function () {
                    Object.defineProperty(String.prototype, 'fromEBCDIC', noEnum(function () {
                                    return decode(this);
                            }));
                    Object.defineProperty(String.prototype, 'fromEBCDICstr', noEnum(function () {
                                    return decodeASCII(this);
                            }));
                    Object.defineProperty(String.prototype, 'toEBCDIC', noEnum(function (urisafe) {
                                    return encode(this, urisafe);
                            }));
            };
    }
    return EBCDIC;
};

var ebcLib = cache("ebcLib", eLib);
var test1 = ebcLib.toEBCDIC("test string 1");

thanks