IsectMP

IsectMP is a middleware multiplexer written in ANSI C that uses blocking RPC's in a single threaded select loop. The goal of IsectMP is to solve the client/server concurrency problem using collections of identical processes rather than threads with the following constraints:

1.    Keep the API as simple as possible to promote language agnosity.
2.    Impose no record structure on the data being exchanged.
3.    Have all data transfer move through a central broker (Isectd).
4.    Be able to stop and start remote processes via Isectd.

1.    IsectMP only wants to solve the Request/Response model.  This is the classic client/server problem where you have a single static server and many clients that come and go.
2.    IsectMP deliberately uses blocking I/O on a single thread in Isectd.  It solves concurrency by breaking down responses from workers into a stream of discrete chunks which must be concatenated at their destination. Requests from clients can be chopped up too, but this is unusual when dealing with databases as requests are usually small while responses can be very large.
3.    IsectMP deliberately forces all communication to pass through Isectd.  While some may argue this is creating a bottleneck, the advantage of having a central broker is that administrators know the health of the entire application by querying Isectd's registers.
4.    Isectd comes supplied with a command language that lets you adjust its state dynamically.
5.    IsectMP comes supplied with a parent daemon (Execd) that can start child processes locally from an instruction sent remotely via Isectd.

It turns out there are lots of other open source libraries out there doing similar things, but they all have different goals in mind from IsectMP.  I freely admit to only knowing IsectMP well, but from what I can see, if you stick with open source:

1.    IsectMP is the only one that uses ANSI C and compiles on Windows without issue.
2.    IsectMP deliberately uses a central broker.  The others frequently try to avoid using a central broker.
3.    IsectMP has the smallest API of any, just five function calls.
4.    IsectMP comes supplied with its own console client that can configure and control the central broker remotely.
5.    IsectMP's two daemons are tiny, the largest daemon weighs in at < 250kB including DLL's.

Certainly IsectMP has it's failings:

1.    It is not asynchronous.
2.    It will only cope with hundreds of clients, since each client gets it's own dedicated socket.
3.    The only transport mechanism it can use is TCP.
4.    It is single threaded.
5.    It's API relies on a C struct which causes headaches when creating new language bindings (2021-08-22  This is no longer true. A lot of reworking to the internals of Isectd has been done since this post was written).

I would not attempt to use IsectMP for an enterprise size application, but for a department size application, IsectMP works very well indeed (2021-08-22 It also does a grand job acting as the middleware behind web sites).

Classmaker on Linux

Recently, I spent the day recommissioning an ancient Windows 2000 box that has lain unused in the back of my office for years.  Periodically, it get's fired up for some experiment or other.  Last time it was used as the database server for ClassmakerLite, but, as none of you were using ClassmakerLite, it went back to sleep again.

This time it was supposed to be used by my children to play Minecraft, but I quickly discovered that nothing much is capable of running on Windows 2000 these days. None of the current crop of Web browsers can manage it except Qupzilla and it was painfully slow.  Earlier versions of Mozilla Firefox work, but they are also too slow.  The only browser that has any speed is Internet Explorer 5.0, but it can't render modern pages properly.  When I found the current release of Java wouldn't install... I gave up.

Thought I might give Classmaker a whirl while I had the box running.  I knew it would run quickly without any issue on Windows 2000 and it did.  But, I wondered, how might it run under Linux using Wine?  I've mused about this before, because I know that Fox-Toolkit uses emulation rather than native operating widget calls to build its GUI and Classmaker's GUI uses Fox-Toolkit exclusively, so in theory, Classmaker should be making very primitive calls into the Wine emulator - calls to routines that must have been present in Wine almost from it's beginning.

I installed Puppy Linux and then installed Wine. Puppy Linux is my favourite Linux distro.  Very easy to install and when you want to get rid of it again, which I invariably do with Linux distros, its a snap.  Took a while to understand how Wine works, but once I did, I had the client side of Classmaker running just fine.  As I already know that Isectd and FirebirdSQL work natively on Linux, although it's been many years since I've run them that way, I can now say that Classmaker as a whole can run on Linux without any code changes being necessary.  Not that I'm going to bother as I've never come across a teacher that uses Linux!  Apple Macs, yes, but I'm not interested in Macs.

The point of this post is to explain what this kind of portability across operating systems means:

1.    Your code base uses external libraries sparingly. The more external libraries your application depends on the higher the probability that the application won't port.
2.    Your code base isn't tied to a vendor specific library that is operating system specific.
3.    Your application uses common fonts and graphic formats.

So what did I have to do to get Classmaker working on Linux?

1.    Copy the following files to a directory somewhere on Linux... Classmaker.exe, isdio_dll.dll, Classmaker.ini  In my case, I just left them in C:\Classmaker\Remote since you usually install Linux on top of an existing Windows box.
2.    Edit Classmaker.ini so that it points to the remote server where Isectd and FirebirdSQL reside.  Here's what my file says:

[Readme]
This file is required so that clients know where the Isectd daemon
is located and what service they are requesting on it.

[IPConfig]
Host=robert-pc:5501
DatabaseService=aotea

3.    Open a Bash terminal and write the following line:

wine start /Unix /mnt/home/Classmaker/Remote/Classmaker.exe

Classmaker starts.

4.    The only thing that had me stumped for a while is Exporting and Importing Unit Plans.  These get written to and read from C:\Classmaker\Transfer.  Found out that Wine emulates the C: drive under /home/$USER/.wine/drive_c  Linux directories preceded by a dot are invisible directories, so I had to go into my home directory and press Ctrl H.  Immediately I could see ~/.wine/drive_c.  Once I added the directories Classmaker/Transfer below ~/.wine/drive_c importing and exporting worked fine.