localhost acks

[Daniel Lee]

Using CL 5.8

In the past I’ve set up localhost interfaces with full HL7 acking.  Is this necessary or does it create an unnecessary bottleneck?  I looked a little at the tcpip-mlp PDL driver and see it doesn’t have acking built in.  I’ve seen others use a different PDL on localhost interfaces that have PDL acking instead of using HL7 acking.

What are your thoughts?

Topic

[David Harrison]

All mine are set up using the tcpip protocol with all the defaults – no Acking. I’m relying on guaranteed delivery as everything is on the same host. Be interested to hear if anyone has had problems.

[Jim Kosloskey]

I would use ACK I would not rely on TCP/IP even on the same host to have proper pacing- the fastest I think would be length encapsulated TCP/IP rather than PDL. Still need a proc but it is quite simple – if you need one let me know.

Also I would set alerts on the inter-site inter-process threads. They will rarely go off but if there is an issue you certainly want to know about it.

I also favor setting up in and out SMAT. Helpful if there is a problem and also for tracking and some statistics.

email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 60 years IT – old fart.

[Daniel Lee]

Jim,

I’ve seen a length encapsulated PDL used where the PDL is set up as acknak.  Is there a reason you would prefer a PDL to do the acking?

I can tell you I would personally rather use a proc because I do not have as good of an understanding of the PDL mechanisms Cloverleaf uses to call the PDL.  I have a better grasp on Cloverleaf’s UPoCs.  I’m still curious as to your reasons why would prefer the proc over the PDL.

I also had a situation occur where I was thankful I was using a length encapsulated ack instead of a standard HL7 ack on a local host interface.  From the symptoms I saw, my theory is someone else created an interface in a different Cloverleaf site with the same port I was using.  If my theory is correct, if I had been using standard acking, my thread would have just delivered the messages to the thread that hijacked my port without caring that it was the wrong thread.  Since my ack structure was different, the sending thread didn’t understand the ack it was receiving from the receiving thread.  I

If you can send me that length encapsulated proc I’d greatly appreciate it.

[Max Drown (Infor)]

Here is tps_acknack.pdl

Code:

/* $Id: tcp_acknak.pdl,v 1.1 1995/02/19 22:55:58 streepy Exp $ */
/*
*
*/

define driver tcp_acknak;
   version: “1.0”;
end driver;

/* This driver manages the transmission of messages using the tcpip
* with a 4-byte length encoded structure.  The length placed in the
* encoding is EXCLUSIVE of the encoding bytes.
*
*   – Upon receiving an IB data message, a one character OB message is
*    sent.  The message is the ASCII value ACK (0x06).
*
*  – Upon sending an OB data message, a one character message is
*    expected in return.  The IB reply message is the ASCII value ACK
*    (0x06).  The current driver does nothing with NAKs other than to
*    print a message saying that a “Negative ack received.”
*
* The phrase basic-msg recognizes this message format.  Once recognized,
* the message data will be available from the ‘data’ field.
*/

define phrase basic-msg;
   field msglen = fixed-array( 4, any );
   length-encoded { encoding:network(bytes:4), store-in: msglen } =
begin
   field data = variable-array( any );
end;
end phrase;

define phrase ack-msg;
   ;
end phrase;

define phrase nak-msg;
   ;
end phrase;

/**********************************************************************
* End of declarative section, TCL management functions start here.   *
**********************************************************************/

#{#

# This is a standard ack/nak protocol; use the acknak style.

hci_pd_msg_style acknak phrase:basic-msg
field:data
ackphrase:ack-msg
nakphrase:nak-msg
rtimeout:30000

#}#

Place it in $HCIROOT/pdls and compile with hcipdc tps_acknack.pdl

-- Max Drown (Infor)

[Daniel Lee]

I notice you do not have a resync set in this PDL.  I think I understand most everything from the PDL structure except the resync.  Can anyone offer an explaination of what that resync does?

[Richard Hart]

Many years ago we moved to use tcp_acknak PDL for communication between Cloverleaf sites and tried many ways to lose a message without success.

For Cloverleaf communication externally we use an ACK based comms.

[John Mercogliano]

You definitely should use application level acks even with local connections.  What we realized is that the recover database is really your friend in high volume instances.  

At the OS level, tcp/ip has it’s own buffer and will store as much info as the client will push up to it’s buffers limit into it the tcp send buffer, but there it is no longer under the control of the recovery database.  If there are messages still in the OS buffer and the server side goes down, you will lose all those messages. With application level acks, you have recover 56 to protect you.  

Also, you don’t have to use the full ack, you can use a minimal, simulated mllp2 style 4 byte ack, as you don’t need to process the local acks you can drop them on the floor.  That cut’s done on the bandwidth for additional acks.

After discussion with Charlie and Goutham about MLLP2, I went with writing my own tcp add-in instead of using the pdl as Charlie pointed out it is still in limited use and the documentation is still confusing.  So, at least with tcl the whole implementation is at your finger tips.  

Here is the code we implemented:

Code:

######################################################################
# Name:      sendMLLP2Ack
# Purpose:   To send an MLLP 2 style ack back to a client connection
#                 NOTE: Only use with our local connections!!!
# UPoC type: tps
# Args:      tps keyedlist containing the following keys:
#            MODE    run mode (”start”, “run”, “time” or “shutdown”)
#            MSGID   message handle
#            CONTEXT tps caller context
#            ARGS    user-supplied arguments:
#                    
#
# Returns:   tps disposition list:
#            
#
# Notes:    
#
# History:  
#                

proc sendMLLP2Ack { args } {
   global HciConnName                             ;# Name of thread
   
   keylget args MODE mode                         ;# Fetch mode
   set ctx “”   ; keylget args CONTEXT ctx        ;# Fetch tps caller context
   set uargs {} ; keylget args ARGS uargs         ;# Fetch user-supplied args

   set debug 0  ;                                 ;# Fetch user argument DEBUG and
   catch {keylget uargs DEBUG debug}              ;# assume uargs is a keyed list

   set module “sendMLLP2Ack/$HciConnName/$ctx” ;# Use this before every echo/puts,
                                                  ;# it describes where the text came from

   set dispList {}                                ;# Nothing to return

   switch -exact — $mode {
       start {
           # Perform special init functions
           # N.B.: there may or may not be a MSGID key in args
           
           if { $debug } {
               puts stdout “$module: Starting in debug mode…”
           }
       }

       run {
           # ‘run’ mode always has a MSGID; fetch and process it
           
           keylget args MSGID mh
keylget args ARGS uarg
set flags [msgmetaget $mh FLAGS]
# If we are resending the message no need for an ack.
if {[lcontain $flags “is_resent”]} {
set dispList [list “CONTINUE $mh”]
} else {
# The mllp 2 protocal sends a single characer 06 as the ack.
# duplicating it here.  This will create a 4 byte ack message.
# the same as the mllp2 pdl driver.
set ackMh [msgcreate -type reply -recover x06]
# set DRIVERCTL for mulitserver
msgmetaset $ackMh DRIVERCTL [msgmetaget $mh DRIVERCTL]
set dispList [list “OVER $ackMh” “CONTINUE $mh”]
}
       }

       time {
           # Timer-based processing
           # N.B.: there may or may not be a MSGID key in args
           
       }
       
       shutdown {
           # Doing some clean-up work
           
       }
       
       default {
           error “Unknown mode ‘$mode’ in $module”
       }
   }

   return $dispList
}

Here is the code is use for the local connections,

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[David Barr]

tcp_acknak.pdl only sends one message at a time. It handles the acks at a lower layer, so I think application acks are superfluous.

[John Mercogliano]

Hi David,

  In this case looking at the PDL it looks like you have duplicated the mllp 2 ack/nak but using length encoding.  Which is very cool.  

Not knowing pdl programming enough as one person pointed out, is there a significance of the missing resync command?

I just wanted to highlight the true pitfall from my own research of not using an ack on local connections.  

As with all things, there are more then one way to skin a cat. For those of use that are not fully versed on PDL programming, tcl can also be a viable and maintainable option.

Thanks,

John Mercogliano
Sentara Healthcare
Hampton Roads, VA

[Author]

Replies