Features of the libmsgque Framework

Basic Force behind the Framework

libmsgque helps you to split your code from one single process into multiple processes.

• The question is: Why you should do this ?

To answer this question have a look to the following examples:

• You are a developer of a portal (perhaps Java) and want to integrate legacy code (perhaps C/C++/Fortran...) into it. Well Java provide you with an interface to the C language called JNI. Well you are done but what happen ?
  The world is bad and the programmer of the legacy code has already retired and from time to time this code crashes and your wonderful java portal will fail and hundreds of users will ask you Why? .... not good
  
  • Let libmsgque keep your legacy code away from your application code
• You are a developer of a wonderful piece of Code, perhaps a library. Well developing code is one task, to convince others to use this library is an other. The problem is that every other has his own view to the world and he believes that his view is the best. It is very common that this view is linked to a specific programming language like java or python.
  Question: how does you integrate your wonderful library into the programming language the users request ?
  
  • Let libmsgque do the job for you. You only have to write on interface to libmsgque and all programming languages are supported as well.
• You are a developer and you have an inspiration to create a wonderful new application, probably a client server application. You are very familiar with one programming language and you want to focus on your application code but don't want to spend time on all the surrounding code necessary to make your application interact with your client or even with other applications you depend on. You don't want to spend time to define a protocol and to do all of the connection-management.
  
  • Let libmsgque do the setup for you and focus on your application.

HOWTO solve this problem

To solve the problem libmsgque is using sockets to link the different parts of your application into a single application. "sockets" have the advantage that they are independent of the operations-system and independent of the programming language used. For libmsgque every single task is using it's own process (argument --fork or --spawn) or thread (argument --thread) and libmsgque is responsible to make this happen.

What is the design specification of LibMsgque ?

guaranteed delivery

libmsgque was designed to support guaranteed delivery. This mean that the data you put into a libmsgque package is exactly the same data the remote site read from the package. If this can not be guaranteed an error is reported to the sender. The data-types supported for guaranteed delivery are available at MqTypeE.

network wide transaction

libmsgque was designed to support network wide transaction. This mean that a transaction started with MqSendEND_AND_WAIT or MqSendEND_AND_CALLBACK is designed to finish successfully or to report an error even if the error-source is not local.

network wide error reporting

libmsgque was designed to control the whole grid of network nodes. This mean that the client get all errors reported local or remote. Remote include not only the direct neighbour it include all network nodes of the grid.

Examples to setup a server

Start a server listen to port MyPort on your alias interface MyHost and --fork , --thread or --spawn for every incoming connection a new server.

server --tcp --fork --host MyHost --port MyPort

Start a server listen to port MyPort on your alias interface MyHost and exit after the first connection.

server --tcp --host MyHost --port MyPort

If (x)inetd is required to start the server use the following line in the (x)inetd.conf file

server --pipe --socket 0

Start a server listen to file LocalFile and fork for every incoming connection a new server.

server --uds --fork --file LocalFile

Start a server listen to file LocalFile and exit after the first connection.

server --uds --file LocalFile

Examples to use a client

Use a client to connect to RemoteHost using RemotePort

client --tcp --host RemoteHost --port RemotePort

Use the setup from above but use my local Interface LocalHost

client --tcp --host RemoteHost --myhost LocalHost --port RemotePort

Use a client to connect to a local server listen to file LocalFile

client --uds --file LocalFile

Use a client start the server using pipe communication

client @ server

Setup a command-pipeline using multiple filter

client @ filter1 @ filter2 @ ...

Setup a command-pipeline using multiple filter, start each filter in an thread

client --thread @ filter1 @ filter2 @ ...