| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Requester channel - cross network |
« View previous topic :: View next topic » |
| Author |
Message
|
| dotaneli |
 Posted: Thu Feb 23, 2006 2:00 am Post subject: Requester channel - cross network |
 |
|
Voyager
Joined: 19 Oct 2005
Posts: 99
Location: Israel
|
Hi,
We connect to another network through a server in a DMZ.
We cannot allow to be a server side, in any connection.
Howerver - the other network needs to send us messages.
I thought of implementing a Requester-Server channel - so we are the client and the other network is the server, but messages flow the other way around.
Problem is in keeping an open tunnel at all times. I suppose there is no way of making the server side to ask the requester to initiate a connection to the server...
Any suggestions? Can requester-sender help me (again... i do not want to be a listener to port 1414 or any other pre-defined port, nor do i want to keep an open tunnel...)
Thank you for every reply, |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Feb 23, 2006 2:46 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
MQ Channels are always one way. You have to explain to the people telling you that you can't be a "server" that you have to be a server.
The best way you have of solving this is by setting up a sender channel to pair with a rcvr on their side, and a requester to pair with the sdr on their side.
The other way I can think to solve this is to have a client application bridge the two qmgrs. Then it can do all the work that an MCA does. And you run risk of losing messages.
You might be able to alleviate some of the concerns using MQIPT to tunnel MQ traffic over port 80. It won't change the nature of what's going on, but your network threat people may be more comfortable.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| csmith28 |
| Posted: Thu Feb 23, 2006 5:56 am Post subject: |
|
|
Grand Master
Joined: 15 Jul 2003
Posts: 1196
Location: Arizona
|
If you set up a SDR/RCVR Channel pair disconnect interval to 0 and the channels will stay running as long as the MQManagers and connectivity to the remote MQManager are stable.
_________________
Yes, I am an agent of Satan but my duties are largely ceremonial. |
|
| Back to top |
|
|
| dotaneli |
| Posted: Sun Feb 26, 2006 3:14 am Post subject: |
|
|
Voyager
Joined: 19 Oct 2005
Posts: 99
Location: Israel
|
Hi.
I experimented in my lab.
As it turns out, you can establish a requester-server pair.
The requester initiates the tcp connecion, but messages flow from the server to the requester...
After checking benchmarking, it turns out that the requester-server pair is able to transfer upto 250 msgs/second, while regular sender-receiver channels support upto 2300 msgs/second...
any one knows why is that?
thanks, |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Feb 26, 2006 12:37 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Have you thought about using SSL on a sender receiver / requester sender pair ?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| wschutz |
| Posted: Sun Feb 26, 2006 1:18 pm Post subject: |
|
|
Jedi Knight
Joined: 02 Jun 2005
Posts: 3316
Location: IBM (retired)
|
| Quote: |
After checking benchmarking, it turns out that the requester-server pair is able to transfer upto 250 msgs/second, while regular sender-receiver channels support upto 2300 msgs/second...
|
Thats surprising, once the channel is established, i would expect the protocol for moving messages the same for both channel pairings .....
EDIT: I did a quick test here, and as expected, for 100K messages, there was no significant difference in time..are you sure your channels have the same batchsz?
_________________
-wayne |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
