MQTT Explorer

Für die unterschiedlichsten Betriebssysteme existieren eine Reihe von Clients für MQTT. MQTT Explorer ist einer dieser Clients, welcher plattformübergreifend (Linux, macOS, Windows) verfügbar ist. Der MQTT Exporer ist auf Performanz optimiert und kommt mühelos mit mehreren tausend Nachrichten pro Minute zurecht. Damit eignet er sich unter anderem für das Debugging größerer Installationen, in welchen unterschiedlichste Topics definiert sind.

Der MQTT Explorer unter macOS

Bezogen werden kann der Client über die Projektseite unter mqtt-explorer.com. Der Quellcode dies Clients kann über GitHub bezogen werden. Lizenziert ist der Quellcode unter der Creative Commons-Lizenz CC-BY-ND und damit keine freie Software.

Maximale URL-Länge bei HTTP

Der Uniform Resource Locator, oder in der Kurzform die URL, wird sicherlich jedem schon begegnet sein. Die URL setzt sich aus einem Schema und einem für das Schema spezifischen Part zusammen. Getrennt werden die beiden Bestandteile durch einen Doppelpunkt. Bei HTTP wäre die Angabe des Schemas (http) und dem anschließenden spezifischen Teil mit dem Host, eventuellen Informationen über den Port, Kennwörter und ähnliches und anschließend der Pfad zur gewünschten Ressource. Interessant ist allerdings die Frage, wie lang darf eine solche URL sein? Kurze URLs wie:

http://api.example.com

machen keinerlei Probleme. In der RFC 2616 finden sich erste Anhaltspunkte dazu. Die RFC trägt den Namen Hypertext Transfer Protocol — HTTP/1.1 und definiert eben dieses Protokoll. Im Abschnitt 3.2, der sich um Uniform Resource Identifiers dreht, findet sich im Unterpunkt 3.2.1 folgender Abschnitt:

The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15).

Aus diesem Abschnitt ergibt sich das URLs so lang wie benötigt sein dürfen und das HTTP-Protokoll keinerlei Beschränkung vornimmt. Sollte der Server eine lange URL nicht verarbeiten können, so soll dieser mit dem Statuscode 414 (URI Too Long) antworten. Gleich danach finden sich ein weiterer Hinweis in der RFC:

Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths.

Dort wird darauf hingewiesen das es Probleme geben kann, wenn die URL länger als 255 Byte ist. Je nach Kodierung und Sprache (wie z.B. Deutsch oder Japanisch), lassen sich eine unterschiedliche Menge an Informationen in diesen 255 Byte kodieren. Allerdings wurde die RFC 2616 durch die RFC 7230 für obsolet erklärt. In dieser RFC findet sich folgender Absatz:

Various ad hoc limitations on request-line length are found in practice. It is RECOMMENDED that all HTTP senders and recipients support, at a minimum, request-line lengths of 8000 octets.

Mit diesem Absatz wird definiert das HTTP-Clients und Server eine Mindestlänge von 8000 Byte unterstützen sollen. In der Praxis stellt sich nun die Frage was wirklich funktioniert. Es existieren durchaus längere URLs, z.B. sogenannte Data-URLs, allerdings sind dies keine HTTP-URLs, sondern definierten ein eigenes Schema. Daneben existieren alte Untersuchungen zu dem Thema. Unabhängig von der theoretischen Machbarkeit existieren weitere Kriterien, wie die maximale Länge die von Suchmaschinen indiziert werden. Hier schwanken die Zahlen zwischen knapp 1800 Byte bis zu 2048 Byte.

Damit lässt sich die Frage nach der maximalen URL-Länge nicht pauschal beantworten. Mit aktueller Software auf Server- und Client-Seite, sollten 1024 Byte für die URL kein Problem sein. Längere URLs sollten mit Vorsicht genossen werden und ihre Sinnhaftigkeit noch einmal hinterfragt werden.

Windows 10 mit integriertem SSH-Client

Seit mittlerweile einigen Monaten findet sich in Windows 10 ein eigener SSH-Client so dass auf Alternativen wie PuTTY zur Not verzichtet werden kann. Ob der Client bereits auf dem Windows-System installiert ist, kann über Systemsteuerung überprüft werden. Dort findet sich der Punkt Optionale Features verwalten.

In der Systemsteuerung kann überprüft werden, welche optionalen Features installiert sind

Ist dort der Punkt OpenSSH-Client aufgeführt so kann dieser, wie der gewöhnliche SSH-Client unter Linux, genutzt werden:

ssh

Ist der SSH-Client nicht installiert, muss das entsprechende Feature erst hinzugefügt werden. Das Projekt bzw. der Quelltext desselben findet sich auf GitHub.

Bibliothek zur Nutzung der MediaWiki-API unter .NET

Für ein kleines Projekt war ich auf der Suche nach einer halbwegs aktuellen Bibliothek zur Nutzung der MediaWiki-API. Wenn man sich auf der entsprechenden Seite in der MediaWiki-Dokumentation umschaut, wird man feststellen das einem nicht all zu viele Bibliotheken zur Verfügung stehen.

Die Auswahl an .NET Bibliotheken fällt eher mager aus

Genutzt habe ich letztendlich die Bibliothek Wiki Client Library, da diese halbwegs aktuell ist und mit meinen MediaWiki-Installationen problemlos zusammenarbeitet. Ein minimales Beispiel zur Bearbeitung einer Wiki-Seite sieht mit der Bibliothek wie folgt aus:

// Init
var client = new WikiClient
{
    ClientUserAgent = "WikiBot"
};

var site = new WikiSite(client, https://wiki.example.com/api.php);

// Login
await site.Initialization;
try
{
    await site.LoginAsync("username", "password");
}
catch (WikiClientException ex)
{
    Console.WriteLine(ex.Message);
}

// Edit site
var page = new WikiPage(site, buildingName);

// Load page
await page.RefreshAsync(PageQueryOptions.FetchContent);

// Update page
page.Content = "new content";
await page.UpdateContentAsync("New page created.", minor: false, bot: true);

// Logout
await site.LogoutAsync();

Über die Nutzung von Generatoren ist es möglich größere Bereiche wie z.B. Kategorien oder Suchergebnisse zu iterieren:

// Iterate all pages
var generator = new AllPagesGenerator(site)
{
    StartTitle = "A",
    NamespaceId = BuiltInNamespaces.Main,
    PaginationSize = 50
};

using (var enumerator = generator.EnumPagesAsync().GetEnumerator())
{
    int index = 0;

    while (await enumerator.MoveNext(CancellationToken.None))
    {
        // Debug output
        var page = enumerator.Current;
        Console.WriteLine("{0}: {1}", index, page);
        index++;

        // Load page
        await page.RefreshAsync(PageQueryOptions.FetchContent);

        // Update page
        page.Content = "new content";
        await page.UpdateContentAsync("Update page.", minor: true, bot: true);
    }
}

Der Quelltext der Wiki Client Library ist auf GitHub zu finden. Lizenziert ist er unter der Apache Licence 2 und damit freie Software.

Clients und Server-Stubs mittels Swagger Codegen erzeugen

Mit Swagger gibt es seit einigen Jahren eine Möglichkeit REST-API sinnvoll zu dokumentieren und zu generieren. Aus einer YAML-Datei, welche die Beschreibung der API enthält kann mit dem Swagger Code Generator (kurz Swagger Codegen) eine entsprechende Client-Bibliothek oder ein Server-Stub erzeugt werden. Eine solche minimale YAML-Datei könnte wie folgt aussehen:

swagger: '2.0'
info:
  description: "API"
  version: "2018.04"
  title: "API"
host: "api.example.com"
basePath: "/v1"
schemes: 
- "https"
paths:
  /tree:
    get:
      produces: 
      - "application/json"
      summary: Returns the document tree
      tags:
      - "Document tree"
      description: Lorem Ipsum dolor sit amet
      responses:
        200:
          description: OK

In dieser Datei wird eine Ressource mit dem Namen tree und für diese eine Get-Methode definiert. Um daraus nun die Client-Bibliotheken bzw. Server-Stubs zu generieren muss der Swagger Codegen über Git bezogen, anschließend kompiliert und paketiert werden:

https://github.com/swagger-api/swagger-codegen.git
cd swagger-codegen
mvn clean package

Zur Erzeugung eines PHP-Server-Stubs mit dem Slim-Framework kann der Swagger Codegen anschließend wie folgt genutzt werden:

java -jar modules/swagger-codegen-cli/target/swagger-codegen-cli.jar generate -i api.yaml   -l slim -o folder/slim

Eine Client-Bibliothek wird auf dem gleichen Weg erzeugt:

java -jar modules/swagger-codegen-cli/target/swagger-codegen-cli.jar generate -i api.yaml   -l javascript -o folder/javascript

In diesem Fall wird eine JavaScript-Client-Bibliothek erzeugt. Die verfügbaren Sprachen bzw. Frameworks für die Clients und Server-Stubs erzeugt werden können, können mit dem Befehl:

java -jar modules/swagger-codegen-cli/target/swagger-codegen-cli.jar langs

angezeigt werden. Die Ausgabe spezifiziert alle vorhandenen Generatoren:

Available languages: [ada, ada-server, akka-scala, android, apache2, apex, aspnetcore, bash, csharp, clojure, cwiki, cpprest, csharp-dotnet2, dart, elixir, elm, eiffel, erlang-client, erlang-server, finch, flash, python-flask, go, go-server, groovy, haskell-http-client, haskell, jmeter, jaxrs-cxf-client, jaxrs-cxf, java, inflector, jaxrs-cxf-cdi, jaxrs-spec, jaxrs, msf4j, java-pkmst, java-play-framework, jaxrs-resteasy-eap, jaxrs-resteasy, javascript, javascript-closure-angular, java-vertx, kotlin, lua, lumen, nancyfx, nodejs-server, objc, perl, php, powershell, pistache-server, python, qt5cpp, r, rails5, restbed, ruby, rust, rust-server, scala, scala-gatling, scala-lagom-server, scalatra, scalaz, php-silex, sinatra, slim, spring, dynamic-html, html2, html, swagger, swagger-yaml, swift4, swift3, swift, php-symfony, tizen, typescript-aurelia, typescript-angular, typescript-inversify, typescript-angularjs, typescript-fetch, typescript-jquery, typescript-node, undertow, ze-ph, kotlin-server]

Lizenziert ist der Swagger Codegen unter der Apache Licence in der Version 2 und somit freie Software.