[Chris Blair]

You’ve proven that you can get to the machine via TCP/IP. If you can’t “telnet {machine ip} {listening port number}”, than their service is not available for connection. If the vendor can “telnet localhost {listening port number}” then their service is up and running but you’re being blocked as an outside host. If that’s the case, my money sayss it’s a software firewall on their system that is not configured to allow outside connections on that listening port.

[Chris Blair]

Sorry for the delayed response, I took some vacation.

I appreciate all the expert advice, I will definately heed your warning.

Thanks again!

[Chris Blair]

Thanks Bob, I appreciate your offer. It’s actually another company that handles the MUMPS/Cache end so I’ll have to see what they want to do.

Did you have consistent success using MUMPS to perform synchronous replies? I’m starting to fom the impression, that’s its better to have 2 one-way pipes.

And to finally answer John’s question, I never get a response unless them I repeatedly send them the message.

[Chris Blair]

It’s a VHA package called HLO. They’re documentation says that do not support synchronous responses, but IHS tweaked the package to make it work. I think that may be the source of our problems.

Michael, each message does have those encapsulation characters. The only thing that I don’t see that I expected to see what a new-line character after the final segment carriage return.  I don’t think that’s an issue, but maybe their software would use that to trigger a buffer flush…?

[Chris Blair]

It looks like I may be getting a short message. In the hex dump of ACKs, it looks like I’m getting about 4.5 messages, but in the next dump I don’t get the rest of the last message. I’m guessing the vendor lost it.

Here’s another piece to the puzzle. When they send me an order, they start waiting for an ACK. The IE transmits the ACK and they’ve confirmed via a software sniffer that the message is sent back to the system. But, they’ll keep sending the same order until eventually they see their ack. They’re using Intersystems Cache’, but it’s not clear how involved with TCP buffers that software gets.

John, I turned off the auto-resend. I’ll send one message per hour and report back when I get my response(s). It’s been 20 minutes since I sent my first one.

[Chris Blair]

Thanks Jim,

Since I have little control over what gets sent in and there could potentially be hundreds of sites connecting — I was looking for more of a hands off approach — just tell ’em what was bad and and move on.

I guess if there are no other suggestions… my best option may be to do some tclproc validation on the incoming message and respond that way. I just have to know what to look for.

Thanks again, Chris.

[Chris Blair]

I’m not sure of the exact coding required but I would be inclined to try the following approach.

1. When a message comes in, make sure it has an accurate start timestamp.

2. On the outbound TPS, calculate the difference between the current time and the start timestamp. Then sleep/wait for 3600 minus that many seconds.

That seems the simplest to me.

You might also want to consider putting this outbound thread in a process that’s seperate from your other mission critical threads. So that message build-up won’t compromise your other interfaces.

[Author]

Replies