We Keep Coding

Can a PINGREQ message be used by a gateway to update a network address in MQTTSN

Im using an MQTTSN Gateway Version 1.2 from;
https://github.com/simon622/mqtt-sn
I notice that a when a client connection goes to sleep and then subsequently wakes up, its IP address may well have changed on the network. When the next PINGREQ message is sent by a client, the gateway is unable to establish its identity from the network address and so the session simply times out.
Is there anyway of updating the network address in this scenario to tie it back to the original session without having the overhead of a new CONNECT?
I tried issuing a new PINGREQ, but the gateway was unable to link the new network address to an existing gateway session.

You're correct in stating that a client may well recycle their IP address during a network event (ie. a network stack power down, or roaming between cells on a cellular network). These events typically require a completely new CONNECT to be issued in order to re-authenticate with a gateway, since typically in SN UDP implementations, the network address is used as part of the identification mechanism. You can CONNECT(clean=false) to maintain session state.
Allowing a client to re-establish (or bind to an existing) session using a PINGREQ alone (with the presence of a clientId) would be very insecure and would present an easy attack vector for session hijacking.
Hope this helps clarify things.

What is the purpose of setting QueueManager property for IBM MQ?

Following this example of sending messages to queue let's look at the part of setting connection factory properties
cf.setStringProperty(WMQConstants.WMQ_HOST_NAME, HOST);
cf.setIntProperty(WMQConstants.WMQ_PORT, PORT);
cf.setStringProperty(WMQConstants.WMQ_CHANNEL, CHANNEL);
cf.setIntProperty(WMQConstants.WMQ_CONNECTION_MODE, WMQConstants.WMQ_CM_CLIENT);
cf.setStringProperty(WMQConstants.WMQ_QUEUE_MANAGER, QMGR);
cf.setStringProperty(WMQConstants.WMQ_APPLICATIONNAME, "JmsPutGet (JMS)");
cf.setBooleanProperty(WMQConstants.USER_AUTHENTICATION_MQCSP, true);
cf.setStringProperty(WMQConstants.USERID, APP_USER);
cf.setStringProperty(WMQConstants.PASSWORD, APP_PASSWORD);
When the line cf.setStringProperty(WMQConstants.WMQ_QUEUE_MANAGER, QMGR); is removed then nothing changes: the client still can successfully send and receive messages.
What is the purpose of setting WMQConstants.WMQ_QUEUE_MANAGER property here?
IBM MQ server is a container based on this Dockefile:
FROM ibmcom/mq:9.2.2.0-r1
ENV LICENSE=accept
ENV MQ_DEV=true
ENV MQ_APP_PASSWORD=app-password
ENV MQ_ADMIN_PASSWORD=admin-pwd
ENV MQ_QMGR_NAME=KUPOL_DEV_QM
Additionally:
In the same example we see the line
destination = context.createQueue("queue:///" + QUEUE_NAME)
and it does not break the app if the prefix "queue:///" is removed, leaving the line as
destination = context.createQueue(QUEUE_NAME).
And I see similar things in multiple examples for IBM MQ across the web.
What is going on with this code? Is it blind copy-pasting or is there an intention?

If you leave queue manager unset or specify a value that is prefixed with a * you can connect to any queue manager name listening on the host and port you specify.
If you specify a queue manager name that is not prefixed with a * then it must match the name of the queue manager listening on the host and port.
You can also use a CCDT to hold the the connection details, in this case (in addition to the above points) the queue manager name you specify is used to look up the connection details in the CCDT. If it is prefixed with a * it will look up the name without the * in the CCDT.
In addition to specifying queue names with the queue:/// prefix, you can also specify topics with the prefix topic:///, my guess is createQueue defaults to assume you are specifying a queue name.

Your sample code appears to be JMS. IBM MQ supports a couple of addressing models for queues.
All three of these mean the same thing:
context.createQueue("MY.QUEUE");
context.createQueue("queue://MY.QUEUE");
context.createQueue("queue:///MY.QUEUE");
However, with the triple-slash you can also fully-qualify REMOTE queues
context.createQueue("queue://QMGRB/MY.OTHER.QUEUE");
This tells IBM MQ to send the message to the QMgr and have it deliver the message to the Remote Queue 'MY.OTHER.QUEUE' on 'QMGRB'.
Note: IBM MQ also supports destination options, so you can modify persistence, priority, character encoding, targetClient, etc. This is useful so you can externalize the configuration and change the message pattern without having to change the code!
ref: https://www.ibm.com/docs/en/ibm-mq/9.0?topic=applications-creating-destinations-in-jms-application

Connecting to IBM MQ using CCDT file in JMS

I am trying to connect to IBM MQ using JMS and client channel definition table (CCDT). I was able to connect successfully to the QueueManager when i specify the MQ properties individually.
But when i try to use CCDT file i get the below exception.
As client channel definition table (CCDT) is used to determine the channel definitions used by client applications to connect to the queue manager i didnt set QueueManager Name.
ERROR> com.ssc.ach.mq.JMSMQReceiver[main]: errorMQJMS2005: failed to create MQQueueManager for ''
javax.jms.JMSException: MQJMS2005: failed to create MQQueueManager for ''
at com.ibm.mq.jms.services.ConfigEnvironment.newException(ConfigEnvironment.java:586)
at com.ibm.mq.jms.MQConnection.createQM(MQConnection.java:2110)
at com.ibm.mq.jms.MQConnection.createQMNonXA(MQConnection.java:1532)
at com.ibm.mq.jms.MQQueueConnection.<init>(MQQueueConnection.java:150)
at com.ibm.mq.jms.MQQueueConnectionFactory.createQueueConnection(MQQueueConnectionFactory.java:174)
at com.ibm.mq.jms.MQQueueConnectionFactory.createConnection(MQQueueConnectionFactory.java:1066)
Iam using the .setCCDTURL(ccdt); method to set the CCDT URL.
private MQQueueConnectionFactory mqQueueConnectionFactory = new MQQueueConnectionFactory();
mqQueueConnectionFactory.setCCDTURL(ccdt);
queueConnection = mqQueueConnectionFactory.createConnection(username, pwd);
When i try to connect using below configuration instead of the CCDT file it connects to the MQ.
mqQueueConnectionFactory.setHostName(host);
mqQueueConnectionFactory.setChannel(channel);
mqQueueConnectionFactory.setPort(port);
mqQueueConnectionFactory.setQueueManager(qManager);
mqQueueConnectionFactory.setTransportType(1);
Do i need to set setQueueManager as well along with the CCDT file , as the exception says failed to create MQQueueManager for ''

The CCDT is not meant to be read in a text editor, it is a binary formatted file. One of the parameters in the CCDT for each CLNTCONN channel is QMNAME. Knowing what QMNAME is set to and how many CLNTCONN channels you have defined in the CCDT and what you want to accomplish will help figure out what value if any should be specified for with setQueueManager.
If there is only one CLNTCONN channel then you could specify the following and it will connect using the single channel no matter what the QMNAME property is set to:
setQueueManager("*");
If there is more than one CLNTCONN channel in the file each with a different QMNAME specified, assuming the name matches the actual queue manager name listening on the host and port associated with the channel you would pass the queue manager name:
setQueueManager("QMGRNAME");
If there is more than one CLNTCONN channels in the file each with the same QMNAME specified where this name is not meant to reflect a actual queue manager name listening on the host and port associated with each channel, this is known as a queue manager group, this would be intended where you want the client to connect to any number of different hosts and ports and you do not need to know which queue manager you are connecting to, in this case you would pass the queue manager group name prefixed with a *:
setQueueManager("*QMGRGROUPNAME");
Another variation of the above is if there is more than one CLNTCONN channels in the file each with an all blank (spaces) or NULL QMNAME specified, this is known as a queue manager group, this would be intended where you want the client to connect to any number of different hosts and ports and you do not need to know which queue manager you are connecting to, in this case you would pass the queue manager name as either a single space or nothing at all ``:
setQueueManager(" ");
//or
setQueueManager("");
The last use case above would likely work if you did not use setQueueManager at all.
If you want to view the contents of the CCDT, you can use the runmqsc command that comes as part of the MQ v8 and higher client or server install.
For Unix ksh/bash shells use the following:
export MQCHLLIB=PATH/OF/CCDT
export MQCHLTAB=NAME_OF_CCDT
runmqsc -n
For Windows use the following:
set MQCHLLIB=PATH/OF/CCDT
set MQCHLTAB=NAME_OF_CCDT
runmqsc -n
Once the runmqsc program has started and displayed Starting local MQSC for 'NAME_OF_CCDT'. you can run the following command to see the channel details:
DIS CHL(*)
Below is a more specific command to narrow the number of fields returned:
DIS CHL(*) QMNAME CONNAME

I haven't look at it in a while but I thought the correct format is:
MQQueueConnectionFactory qcf = new MQQueueConnectionFactory();
qcf.setQueueManager(qManager);
qcf.setCCDTURL(ccdt);
conn = qcf.createConnection(username, pwd);

PCFMessageAgent - Authentication

How does the PCFMessageAgent with the following constructor gets authenticated. What are the user/configuration permissions required to be set. I connect to MQ of version 8.0.0.4.
public PCFMessageAgent(java.lang.String host,
int port,
java.lang.String channel)
throws MQException

You do not provide enough details to give an exact answer. That constructor does not allow for authentication, it connects to the host/port/channel specified but does not pass a username/password or allow for the use of a cetificate.
If the channel on the queue manager does not require CONNAUTH (ex: "CHKCLNT(OPTIONAL)") or TLS (ex: SSLCIPH/SSLPEER) and you are not blocked by CHLAUTH rules, you may be able to connect.
To determine what user MQ would use for authorization would depend on what user your java process is running under, the MCAUSER attribute of the channel, and any CHLAUTH rules that could map you to a different MCAUSER. Based on the final MCAUSER value, MQ would check if you have permission to the SYSTEM.ADMIN.COMMAND.QUEUE and the model queue used to create a temporary dynamic queue for replies.
If you want to provide a username and password or use certificates you would need to create a MQQueueManager and pass this instead of host/port/channel using this constructor:
PCFMessageAgent(MQQueueManager qmanager)
Initializes a new PCFMessageAgent with an existing queue manager connection.

connect to a lacewing server chat

I'm trying to make a port of a chat program a friend of mine made with lacewing and multimedia fusion 2 for android device.
I've managed to create a socket connecting to the listening socket of the server successfully, but I cannot seem to be able to send data to login and enter the chat. The login for now just requires a name, but even if I send a String of data, the server doesn't seem to reply or accept that data to get me over the channel.
I know I could easily port this with other way like using the NDK of the multimedia fusion 2 exporter, but I just want to figure out how this works
PS: I'm using Java and libgdx for the development

You need to read the liblacewing relay protocol:
https://github.com/udp/lacewing/blob/0.2.x/relay/current_spec.txt
On initial connection, you have to send byte 0 to identify that you are not an HTTP client. After this, you can exchange normal protocol messages.
The first message you need to send is the connection request (which may be denied by the server with a deny message). This would be:
byte 0 (2.1.0 request)
(1.2 size)
byte 0 (2.1.0.0 connection request)
string "revision 3" (2.1.0.0 connection request -> version)
When the server responds with response 0 (2.2.0.0 Connect), you then have to set a name before you may join any channels. This is done with message 2.1.0.1 SetName, which is the same structure as above but instead of 2.1.0.0's byte 0, it is 2.1.0.1's byte 1, followed by the name as a string instead of the protocol version.
The server should then respond with 2.2.0.1 SetName, assuming it accepted your name change request. You should process this message in case the server gave you a different name than you requested. Finally, once you have a name, you can join a channel with 2.1.0.2 JoinChannel. The flags you specify here will be used if the channel doesn't exist yet (e.g. nobody is in the chat yet) - these should match the ones in the MMF2 project file. The name should also match.
After all that, you're still not done! You have to process more messages, etc. it's almost like writing the RelayClient class yourself. It's a tough task, but with the protocol specification in hand you should be able to work it all out.