This is not about real Laplanders (with one 'p'). This is about the LAppS microservice application server.

If interested, then I ask under the cat.

Only 6 days have passed since my first posting on the LAppS topic. During these 6 days, LAppS was updated to version 0.6.2 and acquired several useful features.

Major change

Now it is possible to execute services that are not dependent on the queue of incoming WebSockets. I'm not quite sure how to call these services:
Standalone, Decoupled, Internal? The main point of these services is that they are "leading", i.e. they determine the flow of the application. They independently establish the rules of interaction with the outside world. Services in LAppS did not block IOWorker I / O before, but there was only one kind of service, the subordinate WebSockets message queue.

As an example, I want to offer the execution of the HTTP server code running LAppS in a similar service. For this, the Kepler project's Xavante HTTP server will be used (see below).

More features

• Two new options are available for configuring IOWorkers.

  
  
  • max_connections - limit on the number of connections with one IOWorker. Previously, this option has been disabled.
  • auto_fragment — auto -fragmentation of outgoing messages (messages are fragmented by the size of the Upper-Layer-Protocol Payload Ethernet frame of ~ 1500 bytes including the size of the envelopes of the entire protocol stack).
  
  

• For applications (services) the option of limiting the maximum length of the incoming message is available (by default, 2 ^ 64 or the limit of available memory).

  
  
• Added nap module for decoupled services. Interface:
  
  • nap: new () - returns a userdata nap object
  • nap: usleep (msecs) is a microsecond sleep method. msecs is a positive integer.
  • nap: nsleep (nsecs) is a nanosecond sleep method (+ -10ns on my machine). nsecs is a positive integer.
  • nap: sleep (sec) - second sleep method. sec is a positive integer.

Launching Xavante under Lappland

Warning: the xavante server is an HTTP 1.1 server without SSL support (that is, it requires frontend SSL in the form of nginx or H2O, for balancing and encrypting traffic). Frontend setup is not considered here.

What you need to do

• Installed from the OS distributions luarocks.
• Installed LAppS-0.6.2. (Installation options can be viewed on the project wiki , for example, use a prepared deb package or install using a Docker file)
• Installed in accordance with the instructions on the project website xavante (2 steps Karl!)

Http.lua service code

The code is copied from the xavante manual , and inserted into the LAppS service code.

local xavante = require "xavante" local hfile = require "xavante.filehandler" local hredir = require "xavante.redirecthandler" http = {} http.__index = http http["init"]=function() webDir = "/tmp/test/"; end http["mustStop"]=function() return must_stop() end http["run"]=function() local simplerules = { { -- URI remapping example match = "^[^%./]*/$", with = hredir, params = {"index.html"} }, { match = ".", with = hfile, params = {baseDir = webDir} } } xavante.HTTP{ server = {host = "*", port = 80}, defaultHost = { rules = simplerules } } xavante.start(http.mustStop,1); end return http 

Before launching LAppS

Since we specified for xavante the root of the filesystem for the html files lua webDir = "/tmp/test/"; then in this directory you need to put index.html

Let's combine the useful with the pleasant, and put there (by renaming) client.html from the examples along with the cbor.js library.

This client uses 3 services:

• echo_lapps - an echo server operating in accordance with the specification of the LAppS protocol.
• time_broadcast - one-second pulse of time
• broadcast_blob - Broadcast blob ~ 4k in size, for the test of auto-fragmentation of sent messages (with a pulse of 5s).

Therefore, we will create a configuration file for these 4 services (including xavante ):

 { "directories": { "applications": "apps", "app_conf_dir": "etc", "tmp": "tmp", "workdir": "workdir" }, "services": { "echo_lapps" : { "internal" : false, "request_target" : "/echo_lapps", "protocol" : "LAppS", "instances" : 3, "max_inbound_message_size" : 1024 }, "http": { "internal": true, "instances": 1 }, "time_broadcast": { "internal": true, "instances": 1 }, "broadcast_blob": { "internal": true, "instances": 1 } } } 

The configuration (lapps.json) must be placed in / opt / lapps / etc / conf /.

The demo applications themselves must be installed if you set LAppS from the deb package. If installed from source, then simply enter the install-examples mac command.

After that, run the Laplanders: / opt / lapps / bin / lapps

To run in daemon mode, you can add the -d option.

Now, if you start http: // localhost in the browser (if the installation went to localhost), you can see the application working (as on KDVP): echo-rps sliding bar-chart, time notification, and if you open the inspector, then the blob output to the console .

Interesting (or not) details

In the http.lua service code, you can see the call to the global function must_stop () . This function returns true if LAppS wants to stop the application. This function is injected into all decoupled services before they are initialized.

Decoupled services have a simplified interface. These are all the same Lua modules, but only two methods must be declared in them: init () and run () . As is obvious from their names, the first one serves for the initialization code, the second one to execute the service.

I have plans:

• "Voracious" Laplanders "" - a study of memory consumption and cpu using valgrind and gperftools;
• "Railwayman" - why LAPS does not use std :: thread from STL, but uses std :: mutex and std :: atomic. Below is the survey. Need-whether on Habré publications about LAppS.

I also need help developing LAppS. The simplest. We need those who are interested in testing it, and we need requests for functionality.

There are a lot of plans in principle, but maybe someone else will benefit from something else, which I just don’t see.