Clovertech

Sending encrypted messages via TCP/IP

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Sending encrypted messages via TCP/IP

  • Creator
    Topic
  • September 16, 2013 at 10:47 pm #53822
    Arslan Khan
    Participant

      We use standard tcp_acknak.pdl to send encrypted messages internally to other sites/interfaces. Once in a while, we notice duplicates on the receiving end. As these are encrypted messages, I am not sure whether we can use mlp_tcp2.pdl with standard ack/nak tcl procs.

      Is there a way we can avoid duplication on the receiving end?

      Thanks.

    • Creator
      Topic
    Viewing 11 reply threads
    • Author
      Replies
      • September 17, 2013 at 1:00 am #79082
        Jim Kosloskey
        Participant

          Do you resend messages upon timeot on the outbound thread?

          That may be what is happening.

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

        • September 17, 2013 at 10:54 pm #79083
          Arslan Khan
          Participant

            We do not have any ack/nack enabled on the outbound thread, thus no await replies option activated.

            Default entry of “-1” under Retries and Interval of “10” is being used under “Outbound Data” section of “Outbound” tab.

          • September 17, 2013 at 11:44 pm #79084
            Jim Kosloskey
            Participant

              Does your Outbound SMAT show messages being duplicated?

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

            • September 18, 2013 at 2:53 am #79085
              Arslan Khan
              Participant

                As these are encrypted messages, we do not enable SMAT on these outbound threads. We do have SMAT on the receiving side which shows the duplicates.

              • September 18, 2013 at 1:06 pm #79086
                Jim Kosloskey
                Participant

                  Without getting into a lot of discussion, I am going to suggest you deploy acknowledgment handling with these internal connections. Wiat for a reply before you send the next message.

                  I don’t think the encryption is the cause of the issue.

                  We have acknowledgment handling with all of our internal threads (and we have a lot) and have not observed duplication as long as we are configured to exchange acknowledgments properly.

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

                • September 18, 2013 at 2:04 pm #79087
                  Arslan Khan
                  Participant

                    We did enable basic ACK/NACK but were still getting duplicates. Based on the info we have so far, We think that duplication may be happening at the protocol level.

                  • September 18, 2013 at 6:08 pm #79088
                    Jim Kosloskey
                    Participant

                      Have you tried using the standard mlp PDL along with recover 33(or 58 or whatever) procs defined on the outbound thread as well as a proc on the inbound thread to generate the ack rather than using a PDL to do the ack?

                      If you have not had the outbound SMAT on how do you know duplicates are not being generated on the outbound?

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

                    • September 18, 2013 at 6:58 pm #79089
                      Arslan Khan
                      Participant

                        We did enable the standard ACK/NAK procs but still encountered the same duplicate issue.

                        Also, we did extensive trouble shooting earlier to eliminate the option of client sending the duplicates.

                      • September 27, 2013 at 10:04 pm #79090
                        Jon Melin
                        Participant

                          Are you doing any filtering of messages from source to destination, such as suppressing messages on the same route? I’ve had correctly coded filtering, not filter suddenly and start sending duplicates down the route. I’d look at that.

                          Thank you

                        • September 27, 2013 at 10:26 pm #79091
                          Arslan Khan
                          Participant

                            As these are encryted messages, we are not doing any filtering. These are straight raw thru.

                          • September 30, 2013 at 5:55 pm #79092
                            David Barr
                            Participant

                              You can’t use MLLP for sending arbitray binary data. It’s possible that this data could contain 0x1C 0x0D in the data, and that is the message termination sequence for MLLP. You could use PROTOCOL:tcpip with length encoding or base64 encode your data before sending it over MLLP.

                              If you already know that your data can’t contain 0x1C then you can ignore this post.

                            • September 30, 2013 at 8:05 pm #79093
                              Arslan Khan
                              Participant

                                We are using PROTOCOL:tcpip with length encoding but still see the duplicates. We’ll try to use base64 encoding and see whether this fixes the issue.

                                Thanks.

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