- This topic has 5 replies, 4 voices, and was last updated 15 years ago by
.
-
Topic
-
Hi All, I am having a strange problem with one of our new receiving systems. We are sending ADT to them. This system resides outside our walls so we are using a VPN connection out through our firewall then in through their firewall. Messages are getting to them but then stopping in the middle of the transaction (the last 3 in a row stopped at 1380 bytes) and then trying to continue with the rest. Their system chokes because there’s no
at the end of the truncated message. The entire message ends up in the RDB in state 14 but also gets to the saved message file indicating that it was ACK’d (right?). Anyone ever run into something like this? Thanks,
Tim
-
Replies
-
-
Sounds like you may have a buffer problem on the receiving side.
The fact that the message is in the SMAT save file does not indicate an ACK was received as the message is placed there when it is sent not after the ACK is received.
In fact, the fact that the message is still in State 14 would indicate the ACK was not sent.
-
We’ve had a couple different issues with systems and the size of the tcp/ip buffer. One system hung up if the message spanned more then one buffer. Another system had an issue if the message was a specific size, splitting the HL7 end of message characters, hex 1c0d across buffers. The code was looking for 1c and then checking for 0d in the next byte. If the 1c and 0d was split across buffers it would hang.
-
-
It may be that the vendor is only reading for one packet and expects all of the data to be there. You may have to introduce him to RFC 793. After all, TCP/IP is a packet based protocol
See http://www.faqs.org/rfcs/rfc793.html
It never ceases to amaze me how many vedors will implement TCP/IP and have no idea of the requirements set forth in the RFC. 🙄
-
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
