Vendor requesting to use the same port # for 2 interfaces

The simple answer is that you are mistaken.  Many people make this mistake because it is somewhat counter-intuitive.

The detailed answer is this:

With a client connection you can use the same port to as many different IP addresses as you would like.  The way it works is basically like a “street address” where the street is the IP address and the house number represents the port.  If you are going to two different streets the house number can be the same on both of the streets as long as the street and the house number are not both the same.

On a server connection this is not possible because you are allocating real resources on your side and you would end up with a port conflict.

On the client side the actual port that you are sending out on is chosen by the inet daemon according to an ephemeral range.  By default the ephemeral range starts at 32768 on AIX but it is a configurable parameter.  This is why you must ensure that the ports you are listening on are not within the ephemeral range.  If they are you could easily experience port conflicts.

How is that for more information than you would have liked…lol.

Yes, as long as the IP address is different then you can point at the same port to your hearts content.

I have used the multiserver option in a testing environment but I have not put it into production anywhere.  From what I gather, you have to use metadata to ascertain which originating system to send the acknowledgement back to.  Not a huge deal but I do not currently have a requirement to use it.  It might make some things easier and reduce our thread count but those are not considerations that make this a “must-have” yet.

The other reason that I have not done this is because I finally have all of the Project Managers, networking folks, developers, etc. that are involved in the process to the point where they understand that using the same port to listen on convinced that doing this will create a port conflict.  Even though I know the technical reasons why this would make that inaccurate in certain instances, I do not want to go back and try reeducate them as to what circumstances would make it okay or not okay.

Ryan,

I think you need to use the MetaData entry to know where to return the Ack.

Jim Kosloskey

Ryan,

You need to set the DRIVERCTL metadata on your ‘reply’ message so that the engine will deliver it to the correct client port.  Just use DRIVERCTL metadata of the message you received to set your ‘reply’ DRIVERCTL metadata, and the engine does the rest (sends it to the right client port); i.e.:

set obMsg [msgcreate

I understand uniqueness of the IP:port combination being required for outbound threads, but how does this work with outbound threads where acknowledgements are required? Where do the acks come back to?

Say I have two outbound threads talking to fred and george on port 12345. If they are sending me acks, how do I know whether the ack on port 12345 came from fred or george?

They come back to the sending IP:port combination.

Think of the connections as a virtual circuit, linking a unique sending IP:port to a unique receiving IP:port.

The outbound to Fred will be:

From QDXIP:ephemeralPort1 to FredIP:12345

The outbound to George will be:

From QDXIP:ephemeralPort2 to GeorgeIP:12345

So messages sent to Fred will leave from QDXIP:ephemeralPort1 and go to FredIP:12345. When Fred sends an ack it will go back the way it came and be received by the “outbound to Fred” thread on QDXIP:ephemeralPort1.

Same with messages sent to George – they will leave from QDXIP:ephemeralPort2 and go to GeorgeIP:12345. When George sends an ack it will go back the way it came and be received by the “outbound to George” thread on QDXIP:ephemeralPort2.