Habarisoft released new versions of its native STOMP client libraries for Delphi / Object Pascal for integration with popular open source message brokers:
Habari STOMP Client libraries enable Object Pascal applications to take advantage of message broker / message queue technology – which is distributed, loosely coupled, reliable and asynchronous – to build integrated systems, using peer-to-peer and publish-subscribe communication models.
The libraries are available for the open source message brokers ActiveMQ, ActiveMQ Artemis, Eclipse OpenMQ and RabbitMQ. ActiveMQ and OpenMQ are also serving as default messaging subsystems in Enterprise Application Servers such as GlassFish, Payara, TomEE+ or WildFly.
Typical use cases of message brokers include: load balancing (distributed processing), client notification in multi-tiered applications, dynamically configuring and controlling software, alerting and logging, and integration with ISAPI, PHP, .NET, Python or Jakarta EE based web applications
New blog post! Scalability improvements in the upcoming RabbitMQ 3.12 release: how to handle millions of clients with the new MQTT engine.https://t.co/SZHCJJCtFs
“Native MQTT shipping in 3.12 turns RabbitMQ into an MQTT broker. It allows connecting millions of clients to RabbitMQ. Even if you do not plan to connect that many clients, by upgrading your MQTT workload to 3.12, you will substantially save infrastructure costs because memory usage drops by up to 95%.”
ScroogeXHTML for Object Pascal is a library which supports a subset of the Rich Text Format (RTF) standard. It converts RTF to HTML5 and XHTML stand-alone documents, or to fragments which can be embedded in other documents. The library is compatible with Delphi 2009+ and Free Pascal 3.2.0.
The 8.3 release adds basic Linux platform support (Free Pascal only).
The Daraja HTTP Framework is a free open source library for Object Pascal (Free Pascal 3.2.0, Delphi 2009+), based on the stand-alone HTTP server component in Internet Direct (Indy).
This release includes a new example application which demonstrates server-sent events.
Full source code now available on GitHub. Covering Internet Direct (Indy), Ararat Synapse, and Synapse SynCrtSock.
This is the second part in a series which explores basic TCP socket use cases and presents them in minimal examples.
For this part, I selected an unusual string terminator byte sequence. The Unicode Character “☃” (U+2603), named Snowman, is not used in any protocol I am aware of. Encoded in UTF-8 it is three bytes long1. Some background: many Internet protocols use carriage return (octet 13) and/or line feed (octet 10) as line terminator. Therefore, some of the TCP socket libraries offer read methods with a configurable line terminator, but limited to these two. However, some (text-oriented) protocols use a different terminator. A notable example is STOMP, which specifies that the content must be terminated with a NULL byte2.
1) In UTF-8 encoding, Snowman is the byte sequence 0xE2 0x98 0x83.
Note: terminators with three or more bytes are supported by the provided code, but very unusual: every additional byte will slow down the request processing considerably.
The clients are tested with a small console application (see below).
program FixedDelimiterClient;
uses
ClientIndySockets10,
//ClientSynapse266,
//ClientSynopseCrtSock,
SysUtils;
const
FIXED_DELIMITER = '' + #$2603; // Snowman
// ☃
SERVER_HOST = '127.0.0.1';
SERVER_PORT = 30000;
procedure Test(ADelimiter: string);
var
Response: string;
begin
WriteLn(Format('try to read from %s:%d delimited with %s',
[SERVER_HOST, SERVER_PORT, ADelimiter]));
Response := ReadDelimited(SERVER_HOST, SERVER_PORT, Utf8Encode(ADelimiter));
WriteLn(Format('received response "%s" - %d bytes',
[Response, Length(Response)]));
end;
begin
try
Test(FIXED_DELIMITER);
Test(FIXED_DELIMITER);
Test(FIXED_DELIMITER);
except
on E: Exception do
begin
WriteLn(E.Message);
end;
end;
ReadLn;
end.
The Internet Direct (Indy) client source code:
function ReadDelimited(AHost: string; APort: Integer; ATerminator: RawByteString): string;
var
Client: TIdTCPClient;
begin
Client := TIdTCPClient.Create;
try
Client.Host := AHost;
Client.Port := APort;
Client.Connect;
Result := Client.IOHandler.ReadLn(ATerminator, IndyTextEncoding_UTF8);
finally
Client.Free;
end;
end;
Notes
Included is a test server which responds with a snowman – delimited UTF-8 text ☃. The test server requires Indy for compilation.
Full source code now available on GitHub. Covering Internet Direct (Indy), Ararat Synapse, and Synapse SynCrtSock.
This is the first part in a series which explores basic TCP socket use cases and presents them in minimal examples, with useful comments regarding not-so-obvious requirements and pitfalls (a.k.a surprising results).
The clients are tested with a small console application (see below).
program FixedLengthClient;
uses
ClientMainIndy10,
SysUtils;
const
CONTENT_LENGTH = 8192;
SERVER_HOST = '127.0.0.1';
SERVER_PORT = 30000;
procedure Test(AExpectedLength: Integer);
var
Response: TBytes;
begin
WriteLn(Format('try to read %d bytes from %s:%d',
[AExpectedLength, SERVER_HOST, SERVER_PORT]));
Response := Read(SERVER_HOST, SERVER_PORT, AExpectedLength);
WriteLn(Format('received %d bytes', [Length(Response)]));
end;
begin
try
Test(CONTENT_LENGTH);
Test(CONTENT_LENGTH - 1);
Test(CONTENT_LENGTH + 1); // (surprise me)
except
on E: Exception do
begin
WriteLn(E.Message);
end;
end;
ReadLn;
end.
The first client uses Internet Direct (Indy). Here is the source code:
(*
This Source Code Form is subject to the terms of the Mozilla Public
License, v. 2.0. If a copy of the MPL was not distributed with this
file, You can obtain one at http://mozilla.org/MPL/2.0/.
*)
unit ClientMainIndy10;
interface
uses
SysUtils;
function Read(AHost: string; APort: Integer; ALength: Integer): TBytes;
implementation
uses
IdTcpClient, IdGlobal, Classes;
function Read(AHost: string; APort: Integer; ALength: Integer): TBytes;
var
Client: TIdTCPClient;
begin
SetLength(Result, ALength);
Client := TIdTCPClient.Create;
try
Client.Host := AHost;
Client.Port := APort;
Client.Connect;
Client.IOHandler.ReadBytes(Result, Length(Result), False);
finally
Client.Free;
end;
end;
end.
Notes
Included is a test server which responds wiith a fixed-length byte array. The test server requires Indy for compilation.
The TIdHTTPServer subclass contains a method to provide client-specific data in the /sse resource. When invoked, it will return a single ping event with a JSON payload, containing the peer IP and port number, and a timestamp:
function TMySSEServer.BuildContentText(
AContext: TIdContext): string;
begin
Result := 'event: ping' + #13
+ Format('data: {"time": "%s", "peer": "%s:%d"}',
[DateToISO8601(Now, False),
AContext.Binding.PeerIP,
AContext.Binding.PeerPort]) + #13#13;
end;
The DoCommandGet method uses the BuildContentText function to provide the event data, and simulates work by sleeping for a random time interval.
Note
The data stream is running in an endless loop (repeat ... until false).
Because the method never terminates, the method calls AResponseInfo.WriteHeader to send the HTTP headers to the client (line 13).
Neither ContentText nor ContentStream can be used to send data to the client. Instead, the event data must be sent by using the Write.. methods of the connection’s IOHandler (line 16).
procedure TMySSEServer.DoCommandGet(AContext: TIdContext;
ARequestInfo: TIdHTTPRequestInfo;
AResponseInfo: TIdHTTPResponseInfo);
var
Data: string;
begin
AResponseInfo.CharSet := 'UTF-8';
if ARequestInfo.Document = '/sse' then
begin
AResponseInfo.ContentType := 'text/event-stream';
AResponseInfo.CacheControl := 'no-store';
AResponseInfo.ContentLength := -2;
AResponseInfo.WriteHeader;
repeat
Data := BuildContentText(AContext);
AContext.Connection.IOHandler.Write(Data);
Sleep(Random(1000));
until False;
end
else
begin
AResponseInfo.ContentType := 'text/html';
AResponseInfo.ContentStream := TFileStream.Create('index.html', fmOpenRead);
end;
end;
Output
When the browser navigates to http://localhost, the server will provide the HTML and the embedded JavaScript will start reading event data from http://localhost/sse:
Notable difference from the previous version:
The server sends a continuous stream of events as response to the HTTP GET request to the /sse resource.
The length of the response is unknown (it is virtually unlimited), therefore the HTTP response must not contain a content-length header.
The connection will not be closed after sending one or more events.
The client will only retry (reconnect and send a new request), if the the server disconnects its end of the connection, or no data is received and the connection times out.
Diagnostics
To see the full response of the server to the GET request, you may use
In this second part, a server application uses the Indy HTTP server to provide a HTML page which uses SSE to update its content with data sent from the server.
Part 2: the basic demo application, some client data added
Ingredient #1: the HTML page with JavaScript
The script now reads two data items from the ping event:
the time stamp, now sent from the server in proper ISO 8601 format
the peer data, which is the remote ip address and port number
The TIdHTTPServer subclass now contains a private method to provide client-specific data in the /sse resource.
function TMySSEServer.BuildContentText(AContext: TIdContext): string;
begin
Result := '';
repeat
Result := Result + 'event: ping' + #13 +
Format('data: {"time": "%s", "peer": "%s:%d"}',
[DateToISO8601(Now, False), AContext.Binding.PeerIP,
AContext.Binding.PeerPort]) + #13#13;
Sleep(100);
until Random < 0.8;
end;
The DoCommandGet method uses the BuildContentText function to provide the event data:
procedure TMySSEServer.DoCommandGet(AContext: TIdContext;
ARequestInfo: TIdHTTPRequestInfo;
AResponseInfo: TIdHTTPResponseInfo);
begin
if ARequestInfo.Document = '/sse' then
begin
AResponseInfo.ContentType := 'text/event-stream';
AResponseInfo.CacheControl := 'no-store';
AResponseInfo.ContentText := BuildContentText(AContext);
end
else
begin
AResponseInfo.ContentType := 'text/html';
AResponseInfo.ContentStream :=
TFileStream.Create('index.html', fmOpenRead);
end;
AResponseInfo.CharSet := 'UTF-8';
end;
Output
When the browser navigates to http://localhost, the server will provide the HTML and the embedded JavaScript will start reading data from the address http://localhost/sse and receive one or more events.
The ping event, which the server sends to the browser, now includes the server time in ISO 8601 format and the peer IP address and port.
Next part
In the next part, the data stream will be sent continuously.
In this article, a server application uses the Indy HTTP server to provide a HTML page which uses SSE to update its content with data sent from the server.
Server-Sent Events (SSE) is a server push technology enabling a client to receive automatic updates from a server via an HTTP connection, and describes how servers can initiate data transmission towards clients once an initial client connection has been established.
In the example application, a TIdHTTPServer subclass is used to deliver the HTML document when a browser accesses it.
Note that the server has to keep connections alive, so the Server property KeepAlive must be set to true:
procedure Test;
begin
Server := TMySSEServer.Create;
try
Server.KeepAlive := True;
Server.Startup;
ReadLn;
finally
Server.Free;
end;
end;
The DoCommandGet method is overriden and looks like this:
procedure TMySSEServer.DoCommandGet(AContext: TIdContext;
ARequestInfo: TIdHTTPRequestInfo; AResponseInfo: TIdHTTPResponseInfo);
var
S: TStream;
C: string;
begin
if ARequestInfo.Document = '/sse' then
begin
AResponseInfo.ContentType := 'text/event-stream';
AResponseInfo.CacheControl := 'no-store';
AResponseInfo.CharSet := 'UTF-8';
C := 'event: ping' + #13
+ Format('data: {"time": "%d"}', [GetTickCount])
+ #13#13;
AResponseInfo.ContentText := C;
AResponseInfo.ResponseNo := 200;
end
else
begin
S := TFileStream.Create('index.html', fmOpenRead);
AResponseInfo.ContentType := 'text/html';
AResponseInfo.ContentStream := S;
AResponseInfo.ResponseNo := 200;
end;
end;
Output
When the browser navigates to http://localhost, the server will provide the HTML and the embedded JavaScript will start reading data from the address http://localhost/sse (and receive only one event). As specified in the HTML spec for EventSource, the client will retry after some seconds:
Each EventSource object has the following associated with it: – A reconnection time, in milliseconds. This must initially be an implementation-defined value, probably in the region of a few seconds.
ScroogeXHTML for Object Pascal is a library which supports a subset of the Rich Text Format (RTF) standard. It converts RTF to HTML5 and XHTML stand-alone documents, or to fragments which can be embedded in other documents. The library is compatible with Delphi 2009+ and Free Pascal 3.2.0. The 8.2 release includes small improvements in the core library and documentation about the new post process API. The installer is now digitally signed.
Habari! Blog 
You must be logged in to post a comment.