Clovertech

Connectivity Issue/Delay Connection until needed

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Connectivity Issue/Delay Connection until needed

  • Creator
    Topic
  • June 15, 2015 at 5:42 pm #54721
    Kaley Grimes
    Participant

      I am currently working with a vendor who my parent hospital also sends data to. We had a persistent connection established for about a month, and a lot of messages were exchanged in that timeframe. One day out of the blue, the Cloverleaf interface would try to send a message and would not receive acks from the vendor application. The vendor is telling me they are not receiving the message. They then bounce their interface, and the message crosses without issue and acks are received.

      The problem I have now is the vendor is refusing to make a change on their end. They indicate the issue needs to be corrected from within Cloverleaf. The vendor wants Cloverleaf to delay the connection until needed.

      I’m not entirely sure I am comfortable having the delay connection setup as a constant configuration. I say this because when I open NetMon I see this interface as always showing red and down. How will I know it’s truely down or having issues?

      Has anyone else had a similar experience? What are your thoughts on this type of configuration and always seeing the thread in a dead status?

    • Creator
      Topic
    Viewing 6 reply threads
    • Author
      Replies
      • June 16, 2015 at 2:14 pm #82710
        Rob Lindsey
        Participant

          I can say from my point of view, having a thread ‘down’ or in any other status other than up or opening, bothers me.

          I would try this if this was happening on my system,  I would stop and start the interface every hour to see if that takes care of the issue with the vendor system.  What it sounds like to me is that there might be an issue with their programming or there might be a firewall that is closing the connection and not letting their system know that the interface has shutdown.

          Rob

        • June 19, 2015 at 1:51 pm #82711
          Kaley Grimes
          Participant

            Wireshark was installed on the receiving system, and a sniffer was setup on my network and the firewall for the receiving system. Apparently, the sniffer is showing Cloverleaf is sending a tcp reset through the firewall but the firewall is not allowing the tcp reset to go to the receiving server.

            The folks on the receiving end are telling me that since Cloverleaf is the source for the tcp reset, we need to fix the issue. I have McKesson and Infor trying to assist but they’re telling me this may have to go to Development since this is not the way Cloverleaf should act.

            #Frustrated!

          • June 22, 2015 at 12:24 am #82712
            Elisha Gould
            Participant

              I’m guessing Mckesson is the server end of the connection?

              Are they able to set up their connection to handle multiple connections?

              Typically when we receive data over a firewall/vpn, we will set up a multi-server connection, because firewalls/vpns typically behave this way. I would hope they can set up their side this way, and this is the way it should be set up on their side for a firewall connection.

              Alturnatively, is this a low throughput connection?

              The only method that is viable on the cloverleaf side is to disconnect after each ack. This is assuming they will allow the next connection immediately or quickly enough to prevent queues.

              To do this set the delay connection until needed and check use DRIVERCTL control. When the ack is recieved from them send a close on the reply.

              ie use the PROTO disposition on the following message in the sms_ib_reply.

                 set myMsgId [msgcreate]

                 set myDriverCtl {}

                 keylset myDriverCtl CLOSE 1

                 keylset myDriverCtl WRITEZERO 0

                 msgmetaset $myMsgId DRIVERCTL $myDriverCtl

            • June 24, 2015 at 7:47 pm #82713
              Kaley Grimes
              Participant

                Thanks for the input.

                After all of the back and forth debating, our parent hospital (on a separate network) found out their firewall is blocking the traffic.

                Cloverleaf was doing what it was supposed to do the whole time. It would try to connect and after so long, the server would send a tcp reset to establish a new handshake. This was found by tcpdump on our Cloverleaf server after our server was accused of being the trouble maker.

                I guess at this point I’m just glad the true issue has been discovered so we can move on.

              • June 24, 2015 at 9:14 pm #82714
                Jim Kosloskey
                Participant

                  This is nearly always true – everyone blames Cloverleaf and rarely is it Cloverleaf. Unfortunately it is usually us who have to prove that – no matter how often it happens.

                  email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

                • June 25, 2015 at 8:47 pm #82715
                  Peter Heggie
                  Participant

                    our team’s motto is “guilty until proven innocent”

                    Peter Heggie

                  • June 26, 2015 at 1:02 pm #82716
                    Terry Kellum
                    Participant

                      An I thought that is was only the Lab that was used as a scapegoat…   😉

                  • Author
                    Replies
                  Viewing 6 reply threads
                  • The forum ‘Cloverleaf’ is closed to new topics and replies.