| Author |
Message
|
| rathnak |
 Posted: Wed May 11, 2016 4:45 am Post subject: Need an example of using Scydata n scyexit on a sender chann |
 |
|
Newbie
Joined: 01 Feb 2014
Posts: 7
|
Hi MQ Gurus,
Scyexit on a rcvr channel would allow connections only from a allowed set of IPs. here this could be a list of sender channel's host.
But how this would work on a sender channel? could you please give a scenario on when this would be useful?
Thanks,
Rathnak |
|
| Back to top |
|
 |
| exerk |
| Posted: Wed May 11, 2016 5:11 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Why not use CHLAUTH to achieve the same thing, and with less hassle?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| hughson |
| Posted: Wed May 11, 2016 6:17 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
While it may sound odd a sender channel can act as an responding type channel in certain setups.
If your security exit is in the business of checking whether inbound connections are allowed, this is applicable to senders too when run in a specific set up.
Normally a sender channel is paired with a receiver channel and the sender channel is where the conversation is initiated but there are other channel types and pairings.
One of those pairings is a sender paired with a requester channel. This pairing can be started from either end with means that sometimes it is the sender that needs to check whether the inbound request is allowed.
Reading the title of your question, I wonder if your question is maybe simpler than I first thought. Above I have answered "when might I use a SCYEXIT that checks IP addresses on a sender channel?" but now I wonder if perhaps your question is just "when might I use a SCYEXIT on a sender channel?"
Sometimes SCYEXITs run as a pair, also there is one defined on the sender and one on the receiver channel and they have a little chat between them before deciding whether the channel will run. This is commonly used with token based security - the sender passes a token, the receiver verifies it and then the channel is allowed to start.
SCYEXITs can do whatever you want to code them to do, the main point is that they run before the channel is fully started and decide the fate of the channel.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| rathnak |
| Posted: Fri May 13, 2016 3:09 pm Post subject: |
|
|
Newbie
Joined: 01 Feb 2014
Posts: 7
|
Thanks a lot Hughson. that was so clear and well explained.  |
|
| Back to top |
|
|
| jcv |
| Posted: Sat May 14, 2016 8:18 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
I never paid close attention to this and always thought that following message channel types can be described (in the most simplistic way which ignores among other things the fact that receipt confirmation is sent once per batch, not once per message) by this pseudo code:
SDR:
socket.connect
loop:
xmitq.get(msg)
socket.send(msg)
socket.recv(receipt_confirmation)
RCVR:
socket.accept
loop:
socket.recv(msg)
destq.put(msg)
socket.send(receipt_confirmation)
RQSTR:
socket.connect
loop:
socket.recv(msg)
destq.put(msg)
socket.send(receipt_confirmation)
SVR:
socket.accept
loop:
xmitq.get(msg)
socket.send(msg)
socket.recv(receipt_confirmation)
That would mean that SDR is paired with RCVR, and RQSTR with SVR. But hughson's post reminded me that this pseudo code is not correct in connect-accept aspect, which means this is not the only possible pairing. I never tried that though, in fact never dealt with RQSTR and SVR at all. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat May 14, 2016 11:02 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Server-requester pair is useful where the requester end of the channel issues the start channel command. Why? Some apps generate messages that accumulate on the sender xmitq for batch delivery - when the requester end decides it is time to do so.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| jcv |
| Posted: Sun May 15, 2016 8:15 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
OK, I see some usefulness in that case: the one who produces messages should worry about resources (such as disk space), not the one who is (not) consuming them. I see further usefulness in hughson's unusual pairing case (SDR RQSTR) too: if channel gets obstructed for a while, and it won't start automatically in a timely manner, and receiving side is more eager to start it, it can do it by using mq means, not by external such as phone or mail.
I never investigated RQSTR and SVR since I thought it was just a less common and less popular alternative to using SDR RCVR pair. So it passed under my radar for all these years. |
|
| Back to top |
|
|
| hughson |
| Posted: Sun May 15, 2016 1:31 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1959
Location: Bay of Plenty, New Zealand
|
Believe it or not, the recommended channel type pairing from IBM was always SVR - RQSTR. This was because it could be started from either end (as can the SDR - RQSTR). For some reason this advice never got taken to heart and the most common pairing you see today is SDR - RCVR.
The difference, in case you're wondering, between SVR - RQSTR and SDR - RQSTR is that in the case which uses the SDR channel, it's known as the call-me-back channel.
When the RQSTR invokes the channel to start, if it's a SDR at the other end, it breaks the communication and remakes it with the details coded in its CONNAME. An extra security mechanism so that you can't just start the channel from somewhere else and steal all the messages off the XmitQ.
Cheers
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
|
|
