Bug 671228 - Ability to specify IP and port client should use when connecting to a broker
Summary: Ability to specify IP and port client should use when connecting to a broker
Keywords:
Status: NEW
Alias: None
Product: Red Hat Enterprise MRG
Classification: Red Hat
Component: qpid-cpp
Version: 1.3
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: ---
: ---
Assignee: mick
QA Contact: MRG Quality Engineering
URL:
Whiteboard:
Depends On:
Blocks: 698367
TreeView+ depends on / blocked
 
Reported: 2011-01-20 19:14 UTC by Andy Goldstein
Modified: 2020-11-04 18:28 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)

Description Andy Goldstein 2011-01-20 19:14:20 UTC
It would be helpful if we could specify the local IP and port that a client uses when connecting to a broker.  For example, if my client machine has the IPs 192.168.0.1 and 10.0.0.1, I would like to be able to choose which IP and specify a particular port to use, e.g. 192.168.0.1 port 9999 or 10.0.0.1 port 7777.  There could potentially be options that could be given to the Connection such as localInterface and localPort to accomplish this.  If localInterface is not given, continue to function as currently implemented.  If localPort is not given, continue to function as currently implemented.

Comment 1 Gordon Sim 2011-01-24 09:10:46 UTC
Can you describe the usecase for this enhancement?

Comment 2 Andy Goldstein 2011-01-24 12:58:42 UTC
Our QA team needs to be able to block access to a particular client at the TCP/IP level (to simulate a connection loss by the client).  The easiest way we could think of to do this was to know the client's local port and eventually block it.

Comment 3 Gordon Sim 2011-01-27 18:01:46 UTC
As a workaround, are you able to turn on logging of the client's allocated port and then use that to block access?

Comment 4 Andy Goldstein 2011-01-27 19:04:58 UTC
That really wouldn't work for our QA efforts.  We need to know the port that will be used prior to any connection attempt, so as to be able to control whether or not the connection attempt will be successful.  Also, in order for the workaround suggested to be viable, the port the client uses upon reconnects would need to be the same port all the time.


Note You need to log in before you can comment on or make changes to this bug.