MLLP client doesn't receive full ack response when expected #44
Comments
|
I have the exact same issue. I'm not sure if the problem is with the ctx manager. From looking at the code the actual implementation of the receive code seems faulty. It's just reading once from the network buffer and that's it. That part of the code should have to iterate reading from the socket, until either the connection is closed or there's a timeout, or there's an end in the MLLP envelope. I don't see any of that in the code. I tried fixing it but I can't get it to work. Appreciate it if somebody would provide a patch. I can definitely provide testing and feedback. |
cezio
added a commit
to cezio/python-hl7
that referenced
this issue
Jun 10, 2022
cezio
added a commit
to cezio/python-hl7
that referenced
this issue
Aug 16, 2022
* mllp_client code updated to react on timeouts from socket, use of argparse instead of obsolete optparse * tests updated to follow new features and convetions
cezio
added a commit
to cezio/python-hl7
that referenced
this issue
Aug 16, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
MLLP client sends HL7 message properly, the server receives it, and tries to send ack message back. However, in many systems, probably due to low-level implementation details, HL7 ack message is divided into smaller chunks and send back as separate TCP packets.
MLLP client may receive the first
\x0bbyte from the response, which is the beginning of the MLLP envelope, then it will close the connection, due to use of ctx manager. Client will never receive full MSH+MSA message. This is against the protocol, and may cause various problems on the other system starting with inability to confirm reception of the message on it's side.I don't have any solution for this yet, but temporary solution would to read the response until some deadline before closing the connection.
The text was updated successfully, but these errors were encountered: