MqContextC_Route_JV_API

MqContextC - setup and manage a routing-link … More...

Collaboration diagram for MqContextC_Route_JV_API:

Functions
native MkBufferListC	jvmqmsgque.MqContextC.RouteGetTree ()
	Java: MkBufferListC ctx.RouteGetTree() → C-API create an overview about all available routing-target and services …
native void	jvmqmsgque.MqContextC.RouteCreate (String route, String service, boolean overwrite)
	Java: ctx.RouteCreate(String route, String service, ?boolean overwrite = false?) → C-API create/delete a routing-link between context an a service using route
void	jvmqmsgque.MqContextC.RouteCreate (String route, String service)
	Java: ctx.RouteCreate(String route, String service, ?boolean overwrite = false?) → C-API create/delete a routing-link between context an a service using route
native void	jvmqmsgque.MqContextC.RouteDelete (String route, String service, boolean overwrite)
	Java: ctx.RouteDelete(String route, String service, ?boolean overwrite = false?) → C-API delete a routing-link created with MqRouteCreate
void	jvmqmsgque.MqContextC.RouteDelete (String route, String service)
	Java: ctx.RouteDelete(String route, String service, ?boolean overwrite = false?) → C-API delete a routing-link created with MqRouteCreate
native MqContextC[]	jvmqmsgque.MqContextC.RouteResolve (String ident, int retnum)
	Java: MqContextC[] ctx.RouteResolve(String ident, ?int retnum = -1?) → C-API return a list of all context belonging to ident …
MqContextC[]	jvmqmsgque.MqContextC.RouteResolve (String ident)
	Java: MqContextC[] ctx.RouteResolve(String ident, ?int retnum = -1?) → C-API return a list of all context belonging to ident …
native void	jvmqmsgque.MqContextC.RouteTraverse (String service, MkBufferListC args)
	Java: ctx.RouteTraverse(String service, ?MkBufferListC args = null?) → C-API traverse a tree down and call service if available.
void	jvmqmsgque.MqContextC.RouteTraverse (String service, String... args)
	Java: ctx.RouteTraverse(String service, ?MkBufferListC args = null?) → C-API traverse a tree down and call service if available.
void	jvmqmsgque.MqContextC.RouteTraverse (String service)
	Java: ctx.RouteTraverse(String service, ?MkBufferListC args = null?) → C-API traverse a tree down and call service if available.
native String	jvmqmsgque.MqContextC.RouteGetPath ()
	Java: String ctx.RouteGetPath() → C-API return the absolut route-connection-string up to the current ctx …
JNIEXPORT jobject JNICALL	Java_jvmqmsgque_MqContextC_RouteGetTree (JNIEnv *env, jobject self)
	Java: MkBufferListC ctx.RouteGetTree() → C-API create an overview about all available routing-target and services …
JNIEXPORT void JNICALL	Java_jvmqmsgque_MqContextC_RouteCreate (JNIEnv *env, jobject self, jstring route, jstring service, jboolean overwrite)
	Java: ctx.RouteCreate(String route, String service, ?boolean overwrite = false?) → C-API create/delete a routing-link between context an a service using route
JNIEXPORT void JNICALL	Java_jvmqmsgque_MqContextC_RouteDelete (JNIEnv *env, jobject self, jstring route, jstring service, jboolean overwrite)
	Java: ctx.RouteDelete(String route, String service, ?boolean overwrite = false?) → C-API delete a routing-link created with MqRouteCreate
JNIEXPORT jobjectArray JNICALL	Java_jvmqmsgque_MqContextC_RouteResolve (JNIEnv *env, jobject self, jstring ident, jint retnum)
	Java: MqContextC[] ctx.RouteResolve(String ident, ?int retnum = -1?) → C-API return a list of all context belonging to ident …
JNIEXPORT void JNICALL	Java_jvmqmsgque_MqContextC_RouteTraverse (JNIEnv *env, jobject self, jstring service, jobject args)
	Java: ctx.RouteTraverse(String service, ?MkBufferListC args = null?) → C-API traverse a tree down and call service if available.
JNIEXPORT jstring JNICALL	Java_jvmqmsgque_MqContextC_RouteGetPath (JNIEnv *env, jobject self)
	Java: String ctx.RouteGetPath() → C-API return the absolut route-connection-string up to the current ctx …

Detailed Description

MqContextC - setup and manage a routing-link …

A routing-link is the connection of two context, the route-source and the route-target, with a unspecifiend number of hub-context in between using a specific service-token.

A single context is identified by the context-identifier as returned by MqClassIdentGet.

A routing-link can be created using Service-Level-Routing or Package-Level-Routing.

• The Service-Level-Routing is using a round-robin-proxy-service on the hub-context to forward an incoming package to the routing-target.
• The Package-Level-Routing is using a routing-database to route the data on the package-level without a service involved.

The difference between Service-Level-Routing and Package-Level-Routing is the public versa private behaviour.

• The Service-Level-Routing route EVERY package send to the hub-context using the service-token to the routing-target, this behaviour is called public.
• The Package-Level-Routing route ONLY the package(s) from the creator (owner) of the route, this behaviour is called private.

Summary:

• The routing-link connect two context, a source-context and a target-context using multiple hub-context in between.
• The routing-link is created with the command ctx.RouteCreate(String route, String service, ?boolean overwrite = false?) using a route-connection-string and a service-token.
• The route-connection-string has a syntax like a UNIX-path, understand an application as a tree with the initial client as the root and multiple server and slave server as directories and subdirectories with the final service as the file-data wanted.
• The Service-Level-Routing is an extension of the already available MqServiceProxyRoundRobin and MqServiceProxyCtx feature.

TCP/IP layer model

The TCP/IP model define the following layers (from: https://www.geeksforgeeks.org/tcp-ip-model/) :

Network Access Layer

This layer corresponds to the combination of Data Link Layer and Physical Layer of the OSI model. It looks out for hardware addressing and the protocols present in this layer allows for the physical transmission of data.

Internet Layer

This layer parallels the functions of OSI’s Network layer. It defines the protocols which are responsible for logical transmission of data over the entire network
The main protocols residing at this layer are :

1. IP – stands for Internet Protocol and it is responsible for delivering packages from the source host to the destination host by looking at the IP addresses in the package headers. IP has 2 versions: IPv4 and IPv6. IPv4 is the one that most of the websites are using currently. But IPv6 is growing as the number of IPv4 addresses are limited in number when compared to the number of users.
2. ICMP – stands for Internet Control Message Protocol. It is encapsulated within IP datagrams and is responsible for providing hosts with information about network problems.
3. ARP – stands for Address Resolution Protocol. Its job is to find the hardware address of a host from a known IP address. ARP has several types: Reverse ARP, Proxy ARP, Gratuitous ARP and Inverse ARP.

Host-to-Host Layer

This layer is analogous to the transport layer of the OSI model. It is responsible for end-to-end communication and error-free delivery of data. It shields the upper-layer applications from the complexities of data.
The two main protocols present in this layer are :

1. Transmission Control Protocol (TCP) – It is known to provide reliable and error-free communication between end systems. It performs sequencing and segmentation of data. It also has acknowledgment feature and controls the flow of the data through flow control mechanism. It is a very effective protocol but has a lot of overhead due to such features. Increased overhead leads to increased cost.
2. User Datagram Protocol (UDP) – On the other hand does not provide any such features. It is the go-to protocol if your application does not require reliable transport as it is very cost-effective. Unlike TCP, which is connection-oriented protocol, UDP is connectionless.

Application Layer

This layer performs the functions of top three layers of the OSI model: Application, Presentation and Session Layer. It is responsible for node-to-node communication and controls user-interface specifications. Some of the protocols present in this layer are: HTTP, HTTPS, FTP, TFTP, Telnet, SSH, SMTP, SNMP, NTP, DNS, DHCP, NFS, X Window, LPD. Have a look at Protocols in Application Layer for some information about these protocols.
Protocols other than those present in the linked article are :

1. HTTP and HTTPS – HTTP stands for Hypertext transfer protocol. It is used by the World Wide Web to manage communications between web browsers and servers. HTTPS stands for HTTP-Secure. It is a combination of HTTP with SSL(Secure Socket Layer). It is efficient in cases where the browser need to fill out forms, sign in, authenticate and carry out bank transactions.
2. SSH – SSH stands for Secure Shell. It is a terminal emulations software similar to Telnet. The reason SSH is more preferred is because of its ability to maintain the encrypted connection. It sets up a secure session over a TCP/IP connection.
3. NTP – NTP stands for Network Time Protocol. It is used to synchronize the clocks on our computer to one standard time source. It is very useful in situations like bank transactions. Assume the following situation without the presence of NTP. Suppose you carry out a transaction, where your computer reads the time at 2:30 PM while the server records it at 2:28 PM. The server can crash very badly if it’s out of sync.

LibMqMsgque layer model

The libmqmsgque layer model is an extension to the TCP/IP layer model.

TCP/IP Application Layer

This layer is used for the libmqmsgque protocol - The protocol is the "language" of the libmqmsgque
library. The layer is defined as protocol-message-format and as protocol-flow-format.

1. protocol-message-format - Example from protocoll_mq.h → this is the "syntax" of the protocol.

    
   struct HdrS {
       MK_STRB         ID[4]             ;   
       MK_STRB         native            ;   
       MK_STRB         charA             ;   
       union HdrIU     ctxId             ;   
       MK_STRB         charS             ;   
       union HdrIU     bdySize           ;   
       MK_STRB         charO             ;   
       MK_STRB         tok[HDR_TOK_LEN]  ;   
       MK_STRB         charT             ;   
       union HdrIU     transSId          ;   
       MK_STRB         charR             ;   
       union HdrIU     routeId           ;   
       MK_STRB         charC             ;   
       MK_STRB         hs                ;   
       MK_STRB         charE             ;   
       MK_STRB         tt                ;   
       MK_STRB         charF             ;   
   };
    
   struct BdyS {
       MK_STRB         ID[4]   ;   
       //MK_STRB       charN   ;   ///< <TT>size: 1 .............. -> total: 4 .. -> character .. -> "+"</TT>
       union HdrIU     numItems;   
       MK_STRB         charE   ;   
   };
    
   struct LtrS {
       MK_STRB   ID[4]                 ;   
       //MK_STRB   charN                 ;   ///< <TT>size: 1 .............. -> total: 4 .. -> character .. -> "+"</TT>
       MK_BINB   ltrP[HDR_ID_SIZE]     ;   
       MK_STRB   charE                 ;   
   };
   #define LTR_SIZE  (3 + 1 + HDR_ID_SIZE + 1)
    
   struct RouS {
       MK_STRB   ID[4]                 ;   
       //MK_STRB   charN                 ;   ///< <TT>size: 1 .............. -> total: 4 .. -> character .. -> "+"</TT>
       MK_BINB   rouP[HDR_ID_SIZE]     ;   
       MK_STRB   charE                 ;   
   };
   #define ROU_SIZE  (3 + 1 + HDR_ID_SIZE + 1)
    
   struct PackageS {
       struct HdrS     hdr     ;   
       struct BdyS     bdy     ;   
   };
    

2. protocol-flow-format - this is the "grammatic" of the protocol.

LibMqMsgque Service Layer

This layer provide the MqContextC-ServiceApi ontop of the Application Layer.

The master-slave-link is used to create a mesh of nodes defined by different parent-context. The master control the slave.

The master-slave-link is used to perform the following tasks:

• report error messages from the slave-context to the master-context
• to create a slave-child-context if a master-child-context is created
• to delete a slave-context if a master-context is deleted

In difference to the client-server-link the master-slave-link connect two independent parent-context in the same process or thread (e.g. node). This leads to the restriction that only the master-context can be a server-context because only one server-context per node is possible.

   node-0   |           node-1/2        |   node-3/4/5
===================================================================

| <- client/server link -> | <- client/server link -> |

             | <-- master/slave link --> |

                           |- client1-0 -|- server3 ...
             |-  server1  -|
             |             |- client1-1 -|- server4 ...
  client0-0 -|
             |-  server2  -|- client1-2 -|- server5 ...

Definition of the "master-context"

• the master-context is a parent-context without a child-context available.
• the master-context is a client-context or a server-context.
• the link between the master-context and the slave-context is done using MqSlaveWorker or MqSlaveCreate

Definition of the "slave-context"

• the slave-context is a parent-context without a child-context available.
• the slave-context is a client-context.
• the slave-context lifetime is controlled by the master-context.
• the slave-context report all error-messages to the master-context.
• the slave-context is identified by a unique-slave-id starting with 0.
• a special form of a slave-context is a worker-context

Definition of the "worker-context"

• the worker-context is a slave-context using the image of the master-context self.
• the master-context can be a server-context or a client-context.
• the worker-context is created using MqSlaveWorker
• the worker-context is identified by a unique-slave-id starting with 0.

Definition of the "slave-id"

• the slave-id is defined at enum MqSlaveE
• a slave is identified in his master-context by a slave-id
• the slave-id work like a defined well-known-port-number in /etc/services
• the slave-id is an integer value with valid values > 0
• it is a good practice to plan the usage of your slave-id(s)
• slave

  slave-id	value	definition
  MQ_SLAVE_MAX	1024	internal: the maximum slave-id … .
  MQ_SLAVE_USER	10	internal: start of user-defined-slave-id .
  MQ_SLAVE_LOOPBACK	0	internal: the loopback-slave-id, (call my own services) .
  MQ_SLAVE_FILTER	1	internal: the filter-slave-id, (on a master get the filter-slave) .
  MQ_SLAVE_MASTER	1	internal: the master-slave-id, (on a slave get the master) .
  MQ_SLAVE_OTHER	1	internal: on the master-ctx get the slave-ctx and on the slave-ctx get the master-ctx .

• range

  range	definition
  0 <= slave-id < MQ_SLAVE_MAX	range of valid slave-id's
  0 <= slave-id < MQ_SLAVE_USER	internale usage
  MQ_SLAVE_USER <= slave-id < MQ_SLAVE_MAX	external usage

Definition of the "LOOPBACK" (0) slave

•    client   |           server            |
  ===========================================
  
  | <--- client/server --->  | <-- loop --> |
  
              | <------ master/slave -----> |
  
    client -- | -- server -- | -- client -- #
                     ==             ==      #
                   server -- | -- client -- #

• the loopback has always the slave-id = 0 .
• the loopback has the same class as the parent, if reflection is not available the MqFactoryInitial is used.
• the loopback is used to call a service on the same process or thread.
• the loopback is a special filter without an additional process or thread to be started.
• the loopback is only internal accessible
• the service called by the loopback need the same attention as the service called by the filter, the context of the service is the loopback-context.
• the loopback can call MqServiceCreate to create a new link between a service-token and a service-method, by default all services from the master-context (the owner of the loopback) are also accessible by the loopback.
• in the service use MqSlaveGetMaster to get the master-context from the loopback-context.
• Example from MyLoopServer.java → create a new loop-server

  package example;
  
  import jvmqmsgque.*;
  import jvmkkernel.*;
  
  // package-item
  final class MyLoopServer extends MqContextC implements MqServerSetupIF {
  
    // set the "mydata" attribute to the master-context
    String mydata = "Hello World";
  
    // Factory Constructor
    public MyLoopServer(MqContextC tmpl) {
      super(tmpl);
    }
  
    // service to serve all EXTERNAL requests for token "HLWO"
    class HLWO_srv implements MqServiceIF {
      public void Callback(MqContextC ctx) {
        // get the "loopback" context
        MqContextC loop = SlaveGet(MqSlaveE.LOOPBACK.get());
        // call the LOOP service on the SAME server
        loop.Send("W","LOOP");
        // answer HLWO with string-return from LOOP
        Send("R", "C", loop.ReadSTR());
      }
    }
  
    // service to serve all INTERNAL requests for token "LOOP"
    class LOOP_srv implements MqServiceIF {
      public void Callback(MqContextC ctx) {
        // get the "master" context 
        MyLoopServer master = ((MyLoopServer)SlaveGetMaster());
        // answer LOOP with data from MASTER->mydata attribute
        Send("R", "C", master.mydata);
      }
    }
  
    // define a service as link between the token "HLWO" and the class "MyFirstService"
    public void ServerSetup() {
      // EXTERNAL: link the "HLWO" service with the "HLWO_srv"
      ServiceCreate("HLWO", new HLWO_srv());
      // INTERNAL: link the "LOOP" service with "LOOP_srv"
      SlaveGet(MqSlaveE.LOOPBACK.get()).ServiceCreate("LOOP", new LOOP_srv());
    }
  
    // -------------------------------------------------------------
  
    // package-main
    public static void main(String[] argv) {
    
      // create the "MyLoopServer" factory… and the instance
      MqContextC srv = MqFactoryC.Add(MyLoopServer.class).New();
  
      try {
        srv.LinkCreate(argv);
        srv.ProcessEvent(MqWaitOnEventE.FOREVER);
      } catch (Throwable e) {
        srv.ErrorCatch(e);
      }
      srv.Exit();
    }
  }
  

Performance analyse

The performance-test is created with:

• pipe
  • Nhi1Exec perfclient.c --parent --wrk ? @ perfserver.c
• spawn, fork, thread
  • Nhi1Exec -r=uds perfserver.c --spawn|fork|thread
  • Nhi1Exec -r=uds perfclient.c --parent --wrk ?
• the number of workers are set with the –wrk option
• the cpu is a xeon with 4/8
• the performance is calculated as worker-context-created / time-in-sec with a ~2sec (default) measurement period.

performance-test code:

• The test-setup is done as:

    perfclient                                worker                            perfserver
    ==========                                ======                            ==========
    |
    |- loop --wrk x
      |- MqSlaveWorker(...)               ->  worker[1] 
      |- MqSend(worker[1],"E","STR0..")   ->  PerfWorker_I160(...)
                                              |- loop endless
                                                |- MqContextCreate(...)
                                                |- MqLinkCreate(...)      <->   MqContextCreate(...)
                                                |- MqContextDelete(...)   <->   MqContextDelete(...)
    |- sleep x sec
    |- loop --wrk x
      |- MqSend(worker[1],"C"..,"END0")   ->  PerfWorker_END0(...)
      |                                       |- stop loop
      |- "callback" - add number to all   <-  |- return #context 

• Using the worker-code:

  // asynchronous call
  static enum MkErrorE PerfWorker_STR0( MQ_SERVICE_CALL_ARGS ) {
    MK_BFL largv = NULL;
    MK_BFL pargv = NULL;
    MK_I32 num   = MqReadI32_e(mqctx);
           pargv = MkBufferListDup(MqReadBFL_e(mqctx));
    enum MkErrorE ret = MK_OK;
   
    if (num == -1) num = 999999;  // endless
   
    // start test until "doNext" is "false" or "num" exceeds
    for (int i=0; doNext && i<num; i++) {
      // CREATE the context
      MQ_CTX ctx = MqContextCreate(NULL, mqctx);
      largv = MkBufferListDup(pargv);
      MqLinkCreate_C (ctx, largv) {
        MqContextErrorMove(mqctx,ctx);
        MqContextDelete(ctx);
        goto error;
      }
   
  //MqSend(ctx,"E","MARK:C","start");
   
      MkBufferListDelete(largv);
   
      // DELETE the context
      MqContextDelete(ctx);
   
      // count the loops
      worker_count++;
   
      // give PerfWorker_END0 time to update "doNext"
      MqProcessEvent(mqctx, MQ_WAIT_NO, MK_TIMEOUT_DEFAULT);
    }
   
  end:
  //printV("ret=%i, Delete=%p\n", ret, largv)
    MkBufferListDelete(largv);
    MkBufferListDelete(pargv);
   
    if (doNext == true) {
      // finish the test WITHOUT "END0" -> test on --num, answer required.
      MqSend_E(mqctx, "R", "I", worker_count);
    }
    return ret;
   
  error:
    if (doNext == true) {
      ret = MkErrorStack_1X(mqctx);
    } else {
      ret = MkErrorReset_1X(mqctx);
    }
    goto end;
  }

performance-test results:

• results generated using the debug environment

  setup	–wrk	# worker-context	performance	info
  pipe	1	2500	1000	the pipe start a new worker-context with spawn
  spawn	1	2500	<1000	same as pipe but use network-protocoll
  fork	1	3800	4000	the fork is faster than spawn
  thread	1	16500	9000	the thread is faster than fork
  pipe	4	8000	4500	the worker scale linear up to number of processors
  spawn	4	7600	<4500	-
  fork	4	23200	11500	-
  thread	4	55500	27500	-
  pipe	8	10000	5500	the additional scaling up to the max hyper-threading does not really help
  spawn	8	9100	<5500	-
  fork	8	23200	11500	-
  thread	8	55500	27500	-

example (C++ syntax)

Route-Connection-String

A client-server connection is defined with the route-connection-string as a composition of "identifier" and is build like a UNIX directory tree with the initial client as root.

Example: GUI/Data Frontend

*
 
               |-header
         |-GUI-|
frontend-|     |-footer
         |
         |-DB
 
*

With --ident-from prefix|factory the identifier is defined as prefix-identifier or factory-identifer.

A route-connection-string is the path between TWO locations in the tree using the UNIX syntax:

short	syntax	direction
dot	.	current-context
double-dot	..	previous-context
slash	/	root-context (the client)
"string"	xxx	next-context with name xxx

path between "DB" and "header"

• relative: ctx.RouteCreate("../GUI/header",service)
• absolute: ctx.RouteCreate("/frontend/GUI/header",service)

path between "footer" and "DB"

• relative: ctx.RouteCreate("../../DB",service)
• absolute: ctx.RouteCreate("/frontend/DB",service)

path between "frontend" and "footer"

• relative: ctx.RouteCreate("GUI/footer",service)
• absolute: ctx.RouteCreate("/frontend/GUI/footer",service)

Service-Layer-Routing

The LibMqMsgque-Service-Layer-Routing create proxy-services (MqServiceProxyRoundRobin ...) between frontend and footer. (example c++)

// 1. on "frontend" create a route to the service "MYSV" on the "footer" passing "GUI"
DOING: frontendCtx.RouteCreate("GUI/footer", "MYSV");
 
// 2. on "frontend" call the route using the "loopback" slave
DOING: frontendCtx.SlaveGet(MQ_SLAVE_LOOPBACK).Send("W", "MYSV:..@..", ..);
 
// 3. on "frontend/GUI" proxy "footer"
INTERNAL: frontendCtx.ServiceProxyRoundRobin("MYSV", GUICtx);
INTERNAL: GUICtx.ServiceProxyRoundRobin("MYSV", footerCtx);
 
// 4. on "footer" call the service "MYSV"
SETUP: footerCtx.ServiceCreate("MYSV", ...);

The MqRouteCreate will take the following action:

1. create a round-robin-proxy on frontend and on GUI using service MYSV
2. check if service MYSV is available on footer

Attention:

1. With the proxy on frontend/GUI no other service with the name MYSV on frontend/GUI is possible and every service-call to frontend or GUI using the service MYSV will be redirected to the service MYSV on footer.
2. The live-time of the Service-Layer-Routing is up to the next MqRouteDelete call using the same arguments. If the proxy-to-footer becomes invalid on a the GUI-context the routing-link will be recreated.
3. The MqRouteCreate can be used multiple times with the same Route-Connection-String and service-token and overwrite=true to guarantee that a route is available.

Package-Layer-Routing

...

A routing-link is the connection of two context, the route-source and the route-target, with a unspecifiend number of hub-context in between using a specific service-token.

A single context is identified by the context-identifier as returned by MqClassIdentGet.

A routing-link can be created using Service-Level-Routing or Package-Level-Routing.

• The Service-Level-Routing is using a round-robin-proxy-service on the hub-context to forward an incoming package to the routing-target.
• The Package-Level-Routing is using a routing-database to route the data on the package-level without a service involved.

The difference between Service-Level-Routing and Package-Level-Routing is the public versa private behaviour.

• The Service-Level-Routing route EVERY package send to the hub-context using the service-token to the routing-target, this behaviour is called public.
• The Package-Level-Routing route ONLY the package(s) from the creator (owner) of the route, this behaviour is called private.

Summary:

• The routing-link connect two context, a source-context and a target-context using multiple hub-context in between.
• The routing-link is created with the command ctx.RouteCreate(String route, String service, ?boolean overwrite = false?) using a route-connection-string and a service-token.
• The route-connection-string has a syntax like a UNIX-path, understand an application as a tree with the initial client as the root and multiple server and slave server as directories and subdirectories with the final service as the file-data wanted.
• The Service-Level-Routing is an extension of the already available MqServiceProxyRoundRobin and MqServiceProxyCtx feature.

TCP/IP layer model

The TCP/IP model define the following layers (from: https://www.geeksforgeeks.org/tcp-ip-model/) :

Network Access Layer

This layer corresponds to the combination of Data Link Layer and Physical Layer of the OSI model. It looks out for hardware addressing and the protocols present in this layer allows for the physical transmission of data.

Internet Layer

This layer parallels the functions of OSI’s Network layer. It defines the protocols which are responsible for logical transmission of data over the entire network
The main protocols residing at this layer are :

1. IP – stands for Internet Protocol and it is responsible for delivering packages from the source host to the destination host by looking at the IP addresses in the package headers. IP has 2 versions: IPv4 and IPv6. IPv4 is the one that most of the websites are using currently. But IPv6 is growing as the number of IPv4 addresses are limited in number when compared to the number of users.
2. ICMP – stands for Internet Control Message Protocol. It is encapsulated within IP datagrams and is responsible for providing hosts with information about network problems.
3. ARP – stands for Address Resolution Protocol. Its job is to find the hardware address of a host from a known IP address. ARP has several types: Reverse ARP, Proxy ARP, Gratuitous ARP and Inverse ARP.

Host-to-Host Layer

This layer is analogous to the transport layer of the OSI model. It is responsible for end-to-end communication and error-free delivery of data. It shields the upper-layer applications from the complexities of data.
The two main protocols present in this layer are :

1. Transmission Control Protocol (TCP) – It is known to provide reliable and error-free communication between end systems. It performs sequencing and segmentation of data. It also has acknowledgment feature and controls the flow of the data through flow control mechanism. It is a very effective protocol but has a lot of overhead due to such features. Increased overhead leads to increased cost.
2. User Datagram Protocol (UDP) – On the other hand does not provide any such features. It is the go-to protocol if your application does not require reliable transport as it is very cost-effective. Unlike TCP, which is connection-oriented protocol, UDP is connectionless.

Application Layer

This layer performs the functions of top three layers of the OSI model: Application, Presentation and Session Layer. It is responsible for node-to-node communication and controls user-interface specifications. Some of the protocols present in this layer are: HTTP, HTTPS, FTP, TFTP, Telnet, SSH, SMTP, SNMP, NTP, DNS, DHCP, NFS, X Window, LPD. Have a look at Protocols in Application Layer for some information about these protocols.
Protocols other than those present in the linked article are :

1. HTTP and HTTPS – HTTP stands for Hypertext transfer protocol. It is used by the World Wide Web to manage communications between web browsers and servers. HTTPS stands for HTTP-Secure. It is a combination of HTTP with SSL(Secure Socket Layer). It is efficient in cases where the browser need to fill out forms, sign in, authenticate and carry out bank transactions.
2. SSH – SSH stands for Secure Shell. It is a terminal emulations software similar to Telnet. The reason SSH is more preferred is because of its ability to maintain the encrypted connection. It sets up a secure session over a TCP/IP connection.
3. NTP – NTP stands for Network Time Protocol. It is used to synchronize the clocks on our computer to one standard time source. It is very useful in situations like bank transactions. Assume the following situation without the presence of NTP. Suppose you carry out a transaction, where your computer reads the time at 2:30 PM while the server records it at 2:28 PM. The server can crash very badly if it’s out of sync.

LibMqMsgque layer model

The libmqmsgque layer model is an extension to the TCP/IP layer model.

TCP/IP Application Layer

This layer is used for the libmqmsgque protocol - The protocol is the "language" of the libmqmsgque
library. The layer is defined as protocol-message-format and as protocol-flow-format.

1. protocol-message-format - Example from protocoll_mq.h → this is the "syntax" of the protocol.

    
   struct HdrS {
       MK_STRB         ID[4]             ;   
       MK_STRB         native            ;   
       MK_STRB         charA             ;   
       union HdrIU     ctxId             ;   
       MK_STRB         charS             ;   
       union HdrIU     bdySize           ;   
       MK_STRB         charO             ;   
       MK_STRB         tok[HDR_TOK_LEN]  ;   
       MK_STRB         charT             ;   
       union HdrIU     transSId          ;   
       MK_STRB         charR             ;   
       union HdrIU     routeId           ;   
       MK_STRB         charC             ;   
       MK_STRB         hs                ;   
       MK_STRB         charE             ;   
       MK_STRB         tt                ;   
       MK_STRB         charF             ;   
   };
    
   struct BdyS {
       MK_STRB         ID[4]   ;   
       //MK_STRB       charN   ;   ///< <TT>size: 1 .............. -> total: 4 .. -> character .. -> "+"</TT>
       union HdrIU     numItems;   
       MK_STRB         charE   ;   
   };
    
   struct LtrS {
       MK_STRB   ID[4]                 ;   
       //MK_STRB   charN                 ;   ///< <TT>size: 1 .............. -> total: 4 .. -> character .. -> "+"</TT>
       MK_BINB   ltrP[HDR_ID_SIZE]     ;   
       MK_STRB   charE                 ;   
   };
   #define LTR_SIZE  (3 + 1 + HDR_ID_SIZE + 1)
    
   struct RouS {
       MK_STRB   ID[4]                 ;   
       //MK_STRB   charN                 ;   ///< <TT>size: 1 .............. -> total: 4 .. -> character .. -> "+"</TT>
       MK_BINB   rouP[HDR_ID_SIZE]     ;   
       MK_STRB   charE                 ;   
   };
   #define ROU_SIZE  (3 + 1 + HDR_ID_SIZE + 1)
    
   struct PackageS {
       struct HdrS     hdr     ;   
       struct BdyS     bdy     ;   
   };
    

2. protocol-flow-format - this is the "grammatic" of the protocol.

LibMqMsgque Service Layer

This layer provide the MqContextC-ServiceApi ontop of the Application Layer.

The master-slave-link is used to create a mesh of nodes defined by different parent-context. The master control the slave.

The master-slave-link is used to perform the following tasks:

• report error messages from the slave-context to the master-context
• to create a slave-child-context if a master-child-context is created
• to delete a slave-context if a master-context is deleted

In difference to the client-server-link the master-slave-link connect two independent parent-context in the same process or thread (e.g. node). This leads to the restriction that only the master-context can be a server-context because only one server-context per node is possible.

   node-0   |           node-1/2        |   node-3/4/5
===================================================================

| <- client/server link -> | <- client/server link -> |

             | <-- master/slave link --> |

                           |- client1-0 -|- server3 ...
             |-  server1  -|
             |             |- client1-1 -|- server4 ...
  client0-0 -|
             |-  server2  -|- client1-2 -|- server5 ...

Definition of the "master-context"

• the master-context is a parent-context without a child-context available.
• the master-context is a client-context or a server-context.
• the link between the master-context and the slave-context is done using MqSlaveWorker or MqSlaveCreate

Definition of the "slave-context"

• the slave-context is a parent-context without a child-context available.
• the slave-context is a client-context.
• the slave-context lifetime is controlled by the master-context.
• the slave-context report all error-messages to the master-context.
• the slave-context is identified by a unique-slave-id starting with 0.
• a special form of a slave-context is a worker-context

Definition of the "worker-context"

• the worker-context is a slave-context using the image of the master-context self.
• the master-context can be a server-context or a client-context.
• the worker-context is created using MqSlaveWorker
• the worker-context is identified by a unique-slave-id starting with 0.

Definition of the "slave-id"

• the slave-id is defined at enum MqSlaveE
• a slave is identified in his master-context by a slave-id
• the slave-id work like a defined well-known-port-number in /etc/services
• the slave-id is an integer value with valid values > 0
• it is a good practice to plan the usage of your slave-id(s)
• slave

  slave-id	value	definition
  MQ_SLAVE_MAX	1024	internal: the maximum slave-id … .
  MQ_SLAVE_USER	10	internal: start of user-defined-slave-id .
  MQ_SLAVE_LOOPBACK	0	internal: the loopback-slave-id, (call my own services) .
  MQ_SLAVE_FILTER	1	internal: the filter-slave-id, (on a master get the filter-slave) .
  MQ_SLAVE_MASTER	1	internal: the master-slave-id, (on a slave get the master) .
  MQ_SLAVE_OTHER	1	internal: on the master-ctx get the slave-ctx and on the slave-ctx get the master-ctx .

• range

  range	definition
  0 <= slave-id < MQ_SLAVE_MAX	range of valid slave-id's
  0 <= slave-id < MQ_SLAVE_USER	internale usage
  MQ_SLAVE_USER <= slave-id < MQ_SLAVE_MAX	external usage

Definition of the "LOOPBACK" (0) slave

•    client   |           server            |
  ===========================================
  
  | <--- client/server --->  | <-- loop --> |
  
              | <------ master/slave -----> |
  
    client -- | -- server -- | -- client -- #
                     ==             ==      #
                   server -- | -- client -- #

• the loopback has always the slave-id = 0 .
• the loopback has the same class as the parent, if reflection is not available the MqFactoryInitial is used.
• the loopback is used to call a service on the same process or thread.
• the loopback is a special filter without an additional process or thread to be started.
• the loopback is only internal accessible
• the service called by the loopback need the same attention as the service called by the filter, the context of the service is the loopback-context.
• the loopback can call MqServiceCreate to create a new link between a service-token and a service-method, by default all services from the master-context (the owner of the loopback) are also accessible by the loopback.
• in the service use MqSlaveGetMaster to get the master-context from the loopback-context.
• Example from MyLoopServer.java → create a new loop-server

  package example;
  
  import jvmqmsgque.*;
  import jvmkkernel.*;
  
  // package-item
  final class MyLoopServer extends MqContextC implements MqServerSetupIF {
  
    // set the "mydata" attribute to the master-context
    String mydata = "Hello World";
  
    // Factory Constructor
    public MyLoopServer(MqContextC tmpl) {
      super(tmpl);
    }
  
    // service to serve all EXTERNAL requests for token "HLWO"
    class HLWO_srv implements MqServiceIF {
      public void Callback(MqContextC ctx) {
        // get the "loopback" context
        MqContextC loop = SlaveGet(MqSlaveE.LOOPBACK.get());
        // call the LOOP service on the SAME server
        loop.Send("W","LOOP");
        // answer HLWO with string-return from LOOP
        Send("R", "C", loop.ReadSTR());
      }
    }
  
    // service to serve all INTERNAL requests for token "LOOP"
    class LOOP_srv implements MqServiceIF {
      public void Callback(MqContextC ctx) {
        // get the "master" context 
        MyLoopServer master = ((MyLoopServer)SlaveGetMaster());
        // answer LOOP with data from MASTER->mydata attribute
        Send("R", "C", master.mydata);
      }
    }
  
    // define a service as link between the token "HLWO" and the class "MyFirstService"
    public void ServerSetup() {
      // EXTERNAL: link the "HLWO" service with the "HLWO_srv"
      ServiceCreate("HLWO", new HLWO_srv());
      // INTERNAL: link the "LOOP" service with "LOOP_srv"
      SlaveGet(MqSlaveE.LOOPBACK.get()).ServiceCreate("LOOP", new LOOP_srv());
    }
  
    // -------------------------------------------------------------
  
    // package-main
    public static void main(String[] argv) {
    
      // create the "MyLoopServer" factory… and the instance
      MqContextC srv = MqFactoryC.Add(MyLoopServer.class).New();
  
      try {
        srv.LinkCreate(argv);
        srv.ProcessEvent(MqWaitOnEventE.FOREVER);
      } catch (Throwable e) {
        srv.ErrorCatch(e);
      }
      srv.Exit();
    }
  }
  

Performance analyse

The performance-test is created with:

• pipe
  • Nhi1Exec perfclient.c --parent --wrk ? @ perfserver.c
• spawn, fork, thread
  • Nhi1Exec -r=uds perfserver.c --spawn|fork|thread
  • Nhi1Exec -r=uds perfclient.c --parent --wrk ?
• the number of workers are set with the –wrk option
• the cpu is a xeon with 4/8
• the performance is calculated as worker-context-created / time-in-sec with a ~2sec (default) measurement period.

performance-test code:

• The test-setup is done as:

    perfclient                                worker                            perfserver
    ==========                                ======                            ==========
    |
    |- loop --wrk x
      |- MqSlaveWorker(...)               ->  worker[1] 
      |- MqSend(worker[1],"E","STR0..")   ->  PerfWorker_I160(...)
                                              |- loop endless
                                                |- MqContextCreate(...)
                                                |- MqLinkCreate(...)      <->   MqContextCreate(...)
                                                |- MqContextDelete(...)   <->   MqContextDelete(...)
    |- sleep x sec
    |- loop --wrk x
      |- MqSend(worker[1],"C"..,"END0")   ->  PerfWorker_END0(...)
      |                                       |- stop loop
      |- "callback" - add number to all   <-  |- return #context 

• Using the worker-code:

  // asynchronous call
  static enum MkErrorE PerfWorker_STR0( MQ_SERVICE_CALL_ARGS ) {
    MK_BFL largv = NULL;
    MK_BFL pargv = NULL;
    MK_I32 num   = MqReadI32_e(mqctx);
           pargv = MkBufferListDup(MqReadBFL_e(mqctx));
    enum MkErrorE ret = MK_OK;
   
    if (num == -1) num = 999999;  // endless
   
    // start test until "doNext" is "false" or "num" exceeds
    for (int i=0; doNext && i<num; i++) {
      // CREATE the context
      MQ_CTX ctx = MqContextCreate(NULL, mqctx);
      largv = MkBufferListDup(pargv);
      MqLinkCreate_C (ctx, largv) {
        MqContextErrorMove(mqctx,ctx);
        MqContextDelete(ctx);
        goto error;
      }
   
  //MqSend(ctx,"E","MARK:C","start");
   
      MkBufferListDelete(largv);
   
      // DELETE the context
      MqContextDelete(ctx);
   
      // count the loops
      worker_count++;
   
      // give PerfWorker_END0 time to update "doNext"
      MqProcessEvent(mqctx, MQ_WAIT_NO, MK_TIMEOUT_DEFAULT);
    }
   
  end:
  //printV("ret=%i, Delete=%p\n", ret, largv)
    MkBufferListDelete(largv);
    MkBufferListDelete(pargv);
   
    if (doNext == true) {
      // finish the test WITHOUT "END0" -> test on --num, answer required.
      MqSend_E(mqctx, "R", "I", worker_count);
    }
    return ret;
   
  error:
    if (doNext == true) {
      ret = MkErrorStack_1X(mqctx);
    } else {
      ret = MkErrorReset_1X(mqctx);
    }
    goto end;
  }

performance-test results:

• results generated using the debug environment

  setup	–wrk	# worker-context	performance	info
  pipe	1	2500	1000	the pipe start a new worker-context with spawn
  spawn	1	2500	<1000	same as pipe but use network-protocoll
  fork	1	3800	4000	the fork is faster than spawn
  thread	1	16500	9000	the thread is faster than fork
  pipe	4	8000	4500	the worker scale linear up to number of processors
  spawn	4	7600	<4500	-
  fork	4	23200	11500	-
  thread	4	55500	27500	-
  pipe	8	10000	5500	the additional scaling up to the max hyper-threading does not really help
  spawn	8	9100	<5500	-
  fork	8	23200	11500	-
  thread	8	55500	27500	-

example (C++ syntax)

Route-Connection-String

A client-server connection is defined with the route-connection-string as a composition of "identifier" and is build like a UNIX directory tree with the initial client as root.

Example: GUI/Data Frontend

*
 
               |-header
         |-GUI-|
frontend-|     |-footer
         |
         |-DB
 
*

With --ident-from prefix|factory the identifier is defined as prefix-identifier or factory-identifer.

A route-connection-string is the path between TWO locations in the tree using the UNIX syntax:

short	syntax	direction
dot	.	current-context
double-dot	..	previous-context
slash	/	root-context (the client)
"string"	xxx	next-context with name xxx

path between "DB" and "header"

• relative: ctx.RouteCreate("../GUI/header",service)
• absolute: ctx.RouteCreate("/frontend/GUI/header",service)

path between "footer" and "DB"

• relative: ctx.RouteCreate("../../DB",service)
• absolute: ctx.RouteCreate("/frontend/DB",service)

path between "frontend" and "footer"

• relative: ctx.RouteCreate("GUI/footer",service)
• absolute: ctx.RouteCreate("/frontend/GUI/footer",service)

Service-Layer-Routing

The LibMqMsgque-Service-Layer-Routing create proxy-services (MqServiceProxyRoundRobin ...) between frontend and footer. (example c++)

// 1. on "frontend" create a route to the service "MYSV" on the "footer" passing "GUI"
DOING: frontendCtx.RouteCreate("GUI/footer", "MYSV");
 
// 2. on "frontend" call the route using the "loopback" slave
DOING: frontendCtx.SlaveGet(MQ_SLAVE_LOOPBACK).Send("W", "MYSV:..@..", ..);
 
// 3. on "frontend/GUI" proxy "footer"
INTERNAL: frontendCtx.ServiceProxyRoundRobin("MYSV", GUICtx);
INTERNAL: GUICtx.ServiceProxyRoundRobin("MYSV", footerCtx);
 
// 4. on "footer" call the service "MYSV"
SETUP: footerCtx.ServiceCreate("MYSV", ...);

The MqRouteCreate will take the following action:

1. create a round-robin-proxy on frontend and on GUI using service MYSV
2. check if service MYSV is available on footer

Attention:

1. With the proxy on frontend/GUI no other service with the name MYSV on frontend/GUI is possible and every service-call to frontend or GUI using the service MYSV will be redirected to the service MYSV on footer.
2. The live-time of the Service-Layer-Routing is up to the next MqRouteDelete call using the same arguments. If the proxy-to-footer becomes invalid on a the GUI-context the routing-link will be recreated.
3. The MqRouteCreate can be used multiple times with the same Route-Connection-String and service-token and overwrite=true to guarantee that a route is available.

Package-Layer-Routing

...

Function Documentation

Java_jvmqmsgque_MqContextC_RouteCreate()

JNIEXPORT void JNICALL Java_jvmqmsgque_MqContextC_RouteCreate	(	JNIEnv *	env,
		jobject	self,
		jstring	route,
		jstring	service,
		jboolean	overwrite )

Java: ctx.RouteCreate(String route, String service, ?boolean overwrite = false?) → C-API
create/delete a routing-link between context an a service using route

Definition at line 1675 of file MqContextC_jv.c.

                                                                                                                                               {
  MQ_CTX hdl = (MQ_CTX)pObj2Hdl(env,"MqContextC",self);
  JavaErrorCheck;
  MkRtSetup_X(hdl);
  MK_STRN route_ptr = (route?(*env)->GetStringUTFChars(env,route,NULL):NULL);
  JavaErrorCheck;
  MK_STRN service_ptr = (service?(*env)->GetStringUTFChars(env,service,NULL):NULL);
  JavaErrorCheck;
  enum MkErrorE errVal = MqRouteCreate(hdl, route_ptr, service_ptr, overwrite);
  MkErrorC_Check(hdl, errVal)
  if (route_ptr) (*env)->ReleaseStringUTFChars(env,route,route_ptr);
  if (service_ptr) (*env)->ReleaseStringUTFChars(env,service,service_ptr);
error:
  return;
}

Java_jvmqmsgque_MqContextC_RouteDelete()

JNIEXPORT void JNICALL Java_jvmqmsgque_MqContextC_RouteDelete	(	JNIEnv *	env,
		jobject	self,
		jstring	route,
		jstring	service,
		jboolean	overwrite )

Java: ctx.RouteDelete(String route, String service, ?boolean overwrite = false?) → C-API
delete a routing-link created with MqRouteCreate

Definition at line 1692 of file MqContextC_jv.c.

                                                                                                                                               {
  MQ_CTX hdl = (MQ_CTX)pObj2Hdl(env,"MqContextC",self);
  JavaErrorCheck;
  MkRtSetup_X(hdl);
  MK_STRN route_ptr = (route?(*env)->GetStringUTFChars(env,route,NULL):NULL);
  JavaErrorCheck;
  MK_STRN service_ptr = (service?(*env)->GetStringUTFChars(env,service,NULL):NULL);
  JavaErrorCheck;
  enum MkErrorE errVal = MqRouteDelete(hdl, route_ptr, service_ptr, overwrite);
  MkErrorC_Check(hdl, errVal)
  if (route_ptr) (*env)->ReleaseStringUTFChars(env,route,route_ptr);
  if (service_ptr) (*env)->ReleaseStringUTFChars(env,service,service_ptr);
error:
  return;
}

Java_jvmqmsgque_MqContextC_RouteGetPath()

JNIEXPORT jstring JNICALL Java_jvmqmsgque_MqContextC_RouteGetPath	(	JNIEnv *	env,
		jobject	self )

Java: String ctx.RouteGetPath() → C-API
return the absolut route-connection-string up to the current ctx …

Definition at line 1746 of file MqContextC_jv.c.

                                                                                               {
  MQ_CTX hdl = (MQ_CTX)pObj2Hdl(env,"MqContextC",self);
  JavaErrorCheck;
  MkRtSetup_X(hdl);
  MK_STRN path_out;
  enum MkErrorE errVal = MqRouteGetPath(hdl, &path_out);
  MkErrorC_Check(hdl, errVal)
  jstring __retVal__S = JC2O(env,path_out);
  return __retVal__S;
error:
  return 0;
}

Java_jvmqmsgque_MqContextC_RouteGetTree()

JNIEXPORT jobject JNICALL Java_jvmqmsgque_MqContextC_RouteGetTree	(	JNIEnv *	env,
		jobject	self )

Java: MkBufferListC ctx.RouteGetTree() → C-API
create an overview about all available routing-target and services …

Definition at line 1659 of file MqContextC_jv.c.

                                                                                               {
  MQ_CTX hdl = (MQ_CTX)pObj2Hdl(env,"MqContextC",self);
  JavaErrorCheck;
  MkRtSetup_X(hdl);
  MK_BFL treeP_out;
  enum MkErrorE errVal = MqRouteGetTree(hdl, &treeP_out);
  MkErrorC_Check(hdl, errVal)
  jobject __retVal__S = MK(MkBufferListC_ObjNew)(MK_RT_CALL env,treeP_out);
  return __retVal__S;
error:
  return 0;
}

Java_jvmqmsgque_MqContextC_RouteResolve()

JNIEXPORT jobjectArray JNICALL Java_jvmqmsgque_MqContextC_RouteResolve	(	JNIEnv *	env,
		jobject	self,
		jstring	ident,
		jint	retnum )

Java: MqContextC[] ctx.RouteResolve(String ident, ?int retnum = -1?) → C-API
return a list of all context belonging to ident …

Definition at line 1709 of file MqContextC_jv.c.

                                                                                                                                {
  MQ_CTX hdl = (MQ_CTX)pObj2Hdl(env,"MqContextC",self);
  JavaErrorCheck;
  MkRtSetup_X(hdl);
  MK_STRN ident_ptr = (ident?(*env)->GetStringUTFChars(env,ident,NULL):NULL);
  JavaErrorCheck;
  MQ_CTX_A __retVal__L = MqRouteResolve(hdl, ident_ptr, retnum);
  jobjectArray ret = (*env)->NewObjectArray(env, (jsize)__retVal__L.size, MQ(Class_ME_CCC_MqContextC), NULL);
  for (MK_NUM num=0; num<__retVal__L.size; num++) {
    (*env)->SetObjectArrayElement(env, ret, num, MQ(MqContextC_ObjNew)(MK_RT_CALL env,__retVal__L.data[num]));
  }
  jobjectArray __retVal__S = ret;
  if (ident_ptr) (*env)->ReleaseStringUTFChars(env,ident,ident_ptr);
  return __retVal__S;
error:
  return 0;
}

Java_jvmqmsgque_MqContextC_RouteTraverse()

JNIEXPORT void JNICALL Java_jvmqmsgque_MqContextC_RouteTraverse	(	JNIEnv *	env,
		jobject	self,
		jstring	service,
		jobject	args )

Java: ctx.RouteTraverse(String service, ?MkBufferListC args = null?) → C-API
traverse a tree down and call service if available.

Definition at line 1728 of file MqContextC_jv.c.

                                                                                                                            {
  MQ_CTX hdl = (MQ_CTX)pObj2Hdl(env,"MqContextC",self);
  JavaErrorCheck;
  MkRtSetup_X(hdl);
  MK_BAC args_hdl = (MK_BAC)pObj2Hdl__null_allow(env,args);
  JavaErrorCheck;
  MK_STRN service_ptr = (service?(*env)->GetStringUTFChars(env,service,NULL):NULL);
  JavaErrorCheck;
  enum MkErrorE errVal = MqRouteTraverse(hdl, service_ptr, args_hdl);
  MkErrorC_Check(hdl, errVal)
  if (service_ptr) (*env)->ReleaseStringUTFChars(env,service,service_ptr);
error:
  return;
}

RouteCreate() [1/2]

void jvmqmsgque.MqContextC.RouteCreate	(	String	route,
		String	service )

Java: ctx.RouteCreate(String route, String service, ?boolean overwrite = false?) → C-API
create/delete a routing-link between context an a service using route

Definition at line 778 of file MqContextC.java.

                                                         {
    RouteCreate (route, service, false);
  }

RouteCreate() [2/2]

native void jvmqmsgque.MqContextC.RouteCreate	(	String	route,
		String	service,
		boolean	overwrite )

Java: ctx.RouteCreate(String route, String service, ?boolean overwrite = false?) → C-API
create/delete a routing-link between context an a service using route

Here is the caller graph for this function:

RouteDelete() [1/2]

void jvmqmsgque.MqContextC.RouteDelete	(	String	route,
		String	service )

Java: ctx.RouteDelete(String route, String service, ?boolean overwrite = false?) → C-API
delete a routing-link created with MqRouteCreate

Definition at line 786 of file MqContextC.java.

                                                         {
    RouteDelete (route, service, false);
  }

RouteDelete() [2/2]

native void jvmqmsgque.MqContextC.RouteDelete	(	String	route,
		String	service,
		boolean	overwrite )

Java: ctx.RouteDelete(String route, String service, ?boolean overwrite = false?) → C-API
delete a routing-link created with MqRouteCreate

Here is the caller graph for this function:

RouteGetPath()

native String jvmqmsgque.MqContextC.RouteGetPath

(

)

Java: String ctx.RouteGetPath() → C-API
return the absolut route-connection-string up to the current ctx …

RouteGetTree()

native MkBufferListC jvmqmsgque.MqContextC.RouteGetTree

(

)

Java: MkBufferListC ctx.RouteGetTree() → C-API
create an overview about all available routing-target and services …

RouteResolve() [1/2]

MqContextC[] jvmqmsgque.MqContextC.RouteResolve

(

String

ident

)

Java: MqContextC[] ctx.RouteResolve(String ident, ?int retnum = -1?) → C-API
return a list of all context belonging to ident …

Definition at line 794 of file MqContextC.java.

                                                  {
    return RouteResolve (ident, -1);
  }

RouteResolve() [2/2]

native MqContextC[] jvmqmsgque.MqContextC.RouteResolve	(	String	ident,
		int	retnum )

Java: MqContextC[] ctx.RouteResolve(String ident, ?int retnum = -1?) → C-API
return a list of all context belonging to ident …

Here is the caller graph for this function:

RouteTraverse() [1/3]

void jvmqmsgque.MqContextC.RouteTraverse

(

String

service

)

Java: ctx.RouteTraverse(String service, ?MkBufferListC args = null?) → C-API
traverse a tree down and call service if available.

Definition at line 807 of file MqContextC.java.

                                             {
    RouteTraverse (service, (MkBufferListC) null);
  }

RouteTraverse() [2/3]

native void jvmqmsgque.MqContextC.RouteTraverse	(	String	service,
		MkBufferListC	args )

Java: ctx.RouteTraverse(String service, ?MkBufferListC args = null?) → C-API
traverse a tree down and call service if available.

Here is the caller graph for this function:

RouteTraverse() [3/3]

void jvmqmsgque.MqContextC.RouteTraverse	(	String	service,
		String...	args )

Java: ctx.RouteTraverse(String service, ?MkBufferListC args = null?) → C-API
traverse a tree down and call service if available.

Definition at line 802 of file MqContextC.java.

                                                             {
    RouteTraverse (service, new MkBufferListC(args));
  }