Consuming MLLP uri cannot be "seen" with localhost or 127.0.0.1 from external

[John F. Berry]

I have an external system sending HL7 messages via MLLP (I could use netty) and if I specify localhost or 127.0.0.1 the external system says the port is not open.  If I use hostname, it works fine.

from("mllp://HOSTNAME:8888")         This works
from("mllp://localhost:8888")  this doesn't (for the external system anyway)

Is this a limitation of the mllp package I'm using, or just "nature of the beast" camel behavior.
I'd like not to have to specify hostname explicitly so I can run this on any machine I execute it on.
I assume it's exposing the port with the explicit hostname, since it has to resolve it "further out" on the networking level than localhost?

Thanks!

[Siano, Stephan]

Hi,

I am not sure if I get your question. If you bind the listening socket to localhost:8888 it is bound to the (IPv4) loopback interface, which is of course only reachable from the local host.

If you want to bind to all interfaces, you would have to use mllp:0.0.0.0:8888 (which would mean all IPv4 interfaces, though I have no clue if this works with MLLP).

If you use HOSTNAME, you will bind to the externally reachable remote interface, which is reachable externally.

Best regards
Stephan

-----Original Message-----
From: John F. Berry <***@yahoo.com.INVALID>
Sent: Donnerstag, 4. Oktober 2018 15:55
To: Users <***@camel.apache.org>
Subject: Consuming MLLP uri cannot be "seen" with localhost or 127.0.0.1 from external

I have an external system sending HL7 messages via MLLP (I could use netty) and if I specify localhost or 127.0.0.1 the external system says the port is not open.  If I use hostname, it works fine.

from("mllp://HOSTNAME:8888")         This works
from("mllp://localhost:8888")  this doesn't (for the external system anyway)

Is this a limitation of the mllp package I'm using, or just "nature of the beast" camel behavior.
I'd like not to have to specify hostname explicitly so I can run this on any machine I execute it on.
I assume it's exposing the port with the explicit hostname, since it has to resolve it "further out" on the networking level t

[John F. Berry]

Thanks Stephan! 
For not knowing my question, you answered it perfectly.  I knew localhost and 127.0.0.1 is a logical loopback, but I did not realize the significance 0.0.0.0.. I've seen that, but thought people used it as a placeholder as to not put in a "real" IP.  I did not realize it was a real thing.  That works wonderful.

On Friday, October 5, 2018, 2:07:46 AM EDT, Siano, Stephan <***@sap.com> wrote:
Hi,

I am not sure if I get your question. If you bind the listening socket to localhost:8888 it is bound to the (IPv4) loopback interface, which is of course only reachable from the local host.

If you want to bind to all interfaces, you would have to use mllp:0.0.0.0:8888 (which would mean all IPv4 interfaces, though I have no clue if this works with MLLP).

If you use HOSTNAME, you will bind to the externally reachable remote interface, which is reachable externally.

Best regards
Stephan

-----Original Message-----
From: John F. Berry <***@yahoo.com.INVALID>
Sent: Donnerstag, 4. Oktober 2018 15:55
To: Users <***@camel.apache.org>
Subject: Consuming MLLP uri cannot be "seen" with localhost or 127.0.0.1 from external

I have an external system sending HL7 messages via MLLP (I could use netty) and if I specify localhost or 127.0.0.1 the external system says the port is not open.  If I use hostname, it works fine.

from("mllp://HOSTNAME:8888")         This works
from("mllp://localhost:8888")  this doesn't (for the external system anyway)

Is this a limitation of the mllp package I'm using, or just "nature of the beast" camel behavior.
I'd like not to have to specify hostname explicitly so I can run this on any machine I execute it on.
I assume it's exposing the port with the explicit hostname, since it has to resolve it "further out" on the networking level than localhost?

Thanks!

[Quinn Stevenson]

You can also use from(“mlll://8888”) and camel-mllp will create the InetSocketAddress without specific a host, so it should work as well.

HTH

Post by John F. Berry
Thanks Stephan!
For not knowing my question, you answered it perfectly. I knew localhost and 127.0.0.1 is a logical loopback, but I did not realize the significance 0.0.0.0.. I've seen that, but thought people used it as a placeholder as to not put in a "real" IP. I did not realize it was a real thing. That works wonderful.
Hi,
I am not sure if I get your question. If you bind the listening socket to localhost:8888 it is bound to the (IPv4) loopback interface, which is of course only reachable from the local host.
If you want to bind to all interfaces, you would have to use mllp:0.0.0.0:8888 (which would mean all IPv4 interfaces, though I have no clue if this works with MLLP).
If you use HOSTNAME, you will bind to the externally reachable remote interface, which is reachable externally.
Best regards
Stephan
-----Original Message-----
Sent: Donnerstag, 4. Oktober 2018 15:55
Subject: Consuming MLLP uri cannot be "seen" with localhost or 127.0.0.1 from external
I have an external system sending HL7 messages via MLLP (I could use netty) and if I specify localhost or 127.0.0.1 the external system says the port is not open. If I use hostname, it works fine.
from("mllp://HOSTNAME:8888") This works
from("mllp://localhost:8888") this doesn't (for the external system anyway)
Is this a limitation of the mllp package I'm using, or just "nature of the beast" camel behavior.
I'd like not to have to specify hostname explicitly so I can run this on any machine I execute it on.
I assume it's exposing the port with the explicit hostname, since it has to resolve it "further out" on the networking level than localhost?
Thanks!