Asynchronous TCP connection with Cloverleaf

Mark,

While from a technical standpoint this could be done, the real question is the validity of such an approach.

The acknowledgements for a message should come back on the same port the message was sent (otherwise how would you ever know to send the next message?).

Now what the customer may be talking about is not an acknowledgment but a response. That is data not an acknowledgment and that certainly could come on another port but the acknowledgment which tells you your mesage was received and it is OK (or not) to send the next message should come on the same port the message is sent.

What kind of message exchange is this? HL/7, X12, proprietary??

They are with the single socks that disappear in your dryer.  😛

Mike,

I suppose someone may have cobbled together something to do what you describe but I have not heard of it.

I have done Asynchronous Data exchange integrations over both SNA and TCL/IP. In both situations the acknowledgment for the message sent comes on the same connection as the message is sent out. The Asynchronous part is the reply to the message (typically these are Query/Reply) not the acknowledgment and that always came on a different connection (although that is possible to have happen on the same connection – the Reply that is).

I can’t believe GE cannot get that working properly – they package Clovelreaf(R) with their products so they have the proper toolset available.

The issue would be how does port 1 wait until port 2 receives the acknowledgement for port 1’s message? The way I might begin to address this (if I were so inclined) would be to write Tcl code to set a file indicating a message has been sent (when I send a message) on port 1 and keep checking to see if that file is still there (this probably means a sleep – not good). Then Port 2 when receiving an acknowledgment would need to check the file Port 1 placed there and if it is an acknowledgment for the same message, remove the file so Port 1 would know it could send another message.

Of course, the above does not address handling of unusual situations and NAKS.

I see real possibility for production errors and possibly even lost messages.

Does GE claim anyone is doing this kjludge with them – more importantly can they give you a contact (doesn’t need to be Cloverleaf(R) shop – the principle issues are the same no matter what tool is used)?

Jim:

I agree that since GE Centricity has at least one ADT real-time TCP/IP interface with us for our Pharmacy system that is fairly standard and sends the ACK back on the same port as we send the message, why isn’t GE offering that as an option.