We have a C++ application connecting as client to WebSphere MQ using configurable queue manager and queue name. We have been asked to migrate to SSL channels for security reasons. So far we have taken care of configuring Sender and Receiver channels to use SSL.
Do we need to move the SVRCONN channels as well to use SSL?
If yes, how do we provide key-store details in code to connect to channel?
I could not find any option in MQOPEN API to provide.
I could not find any option in MQOPEN API to provide.
Its not in MQOPEN but rather MQCONNX API call. It is far better to use a CCDT (Client Channel Definition Table) file because then your code just needs to issue an MQCONN API call.
Related
I have a nodeJS server which receives user POST/Streaming requests from a web-UI.
I have a C++ back-end engine process which does some calculations and sends API calls to other 3rd party services. The API call requires certain info provided by the web users.
My question is what is the best solution to pass the request data received on NodeJS and send over to the C++ process?
WebUI -> NodeJS ->???->> C++ engine
Make your C++ application listen on a TCP or Unix socket.
Make your NodeJs application connect to that socket and exchange messages. For messages you can use Google Protocol Buffers, JSON, etc..
If the information what you have is still at JavaScript layer, then you have to implement C/C++ Addons implementation. If you already have some type of native module, then you may follow the same design based on that (very likely existing module could be based on NAN). If you are plan to introduce a brand new native module then it is a good time to consider N-API. You can get more information about it from.
https://nodejs.org/dist/latest-v11.x/docs/api/n-api.html
https://github.com/nodejs/node-addon-api
We are working on connecting mesh nodes to Amazon Web Services. Mesh nodes are by nature constrained devices and we can't afford to run MQTT on those nodes directly (TCP is too expensive)
Our approach would be to use CoAP for the mesh but it would be ideal if we could connect those nodes directly to AWS for security reasons and nodes management from the cloud.
AWS supports HTTP but not CoAP directly. From what we have gathered, CoAP is very similar to HTTP. It also uses similar security mechanism (DTLS vs TLS).
Has anyone tried this? Is it possible that a simple CoAP to HTTP proxy would be capable of maintaining a securied session between CoAP device and HTTP broker on AWS?
Unfortunately I can't tell anything about proxies (except that the approach seems somewhat clunky at first view).
But before that, can you afford DTLS on your mesh nodes?
For example, you will need a good and fast random source.
Every handshake will require to generate a 32-byte random "cookie".
Assume we use pre-shared keys and AES128 with CCM8 (since where could be no point to use something more simple):
Every CoAP packet will be encrypted and extended to:
DTLS header: 13 bytes
Nonce: 16 bytes
Also you will need to store a few packets during a handshake (I can't tell the exact size but I suppose it is hundreds of bytes).
Anyway, it depends on that security level do you want to get.
A cross-proxy definition already exists in the CoAP specification CoAP specification, RFC7252, Section 10
The open source project Eclipse/Californium contains such a proxy implementation. See Proxy 2, README, for more details.
I'm newbie to AWS and trying to work on the SQS for the first time. I've an Oracle Service Bus (OSB) in non-cloud environment and would like to configure OSB to consume messages from Amazon SQS. The documentation mentions to use REST API and poll repeatedly for messages. I also read about the 'client library for JMS' so that the OSB could treat SQS as JMS provider. What is the best approach to achieve this? Appreciate your inputs.
The easiest (not necessarily the purest way) would be to create a Java EE app that imports the SQS libraries and pulls messages from AWS and puts them on a local queue for OSB to process. The example code snippets are in Java, so it should be relatively straight forward.
The purest way would be to set it up as a remote JMS provider. However, how to set that up is not so clear - you may end up writing most of the code that went into option #1 above, but making a JMS client library instead of a MDB.
My application runs in Windows and is implemented using C++/Qt.
The application will invoke another application deployed in the Linux server which in turn will invoke some third party tools. The Linux server application will send some status updates based on the running of third party tools. Usually the third party application will run for hours and the updates will be sent at various stages. The Linux server may also has to send some files in addition to the status updates and the Windows client will also send some files required for the running of those third party tools.
I planned to implement this in libssh2 since file transfers can be done and applications can be executed as well using libssh2_channel_exec(). Updates can be sent and received through non-blocking socket transfers. Also the transfers must be secured and they are password authenticated, so I thought SSH will conform my requirements.
I also looked into Qpid of apache which implements the AMQP. The messaging seems to be a more appropriate one for my status updates since the updates are less frequent. But I am not so sure about the secured connection, password authentication and also the application invocation.
So, which one can I choose between these two? Or is there any other better option available? I am not quite used to network programming so any pointers, links regarding this are welcome..
Have you considered some web-based solutions like XML-RPC, REST, SOAP or other? Note that you can either have constant network connection and stream updates or just make your client ask for update as often as it needs.
Also, I think that building solution based on some of these protocols will give you easier coding - no need for some low-level solutions when you have great libraries. As for security part, I would consider SSL that is part of HTTPS protocol to be secure enough. Of course you can also do it hybrid style, for example SSH tunel to secure server and use SSH key authorization.
But if you are sure youwant SSH or AMQP then use first one - I think it has better security. Also, try not using username/passowrd. Instead use mentioned above keys.
Start with SSH, and then consider layering other protocols on top. You can use SSH port forwarding to create a VPN connection to a server, and maybe that will make it easier to use something like AMQP or 0MQ.
It is easy to display the status of a Windows service or to control it (start/stop) from a GUI application but the question if how about receiving/sending notifications from the service? Like: service telling to the user monitoring it that it needs attention.
Please consider that you can have several controllers started at any time in a multi-user environment.
Do you know an example(open source) for this kind of communication?
Extra points for a platform independent solution :)
If the "user" monitoring the service is a person, how about writing to an event log and then having your enterprise event monitoring system send alerts. Alternatively, have the service log the issue to the event log and then send an email.
If the "user" or client of the service is a separate or multiple applications here are a couple thoughts without fully understadning your problem.
Write to file. Have the client tell the service what file or some agreed token to create a file for that particular client instance and then have the service write to the file. The client can then monitor the file.
Status Ping. Have the client ping the service on a regular basis in a background thread to ask the service how it is doing. If unhealthy, then the client could ping the service for more information. Kind of like getting the LastMessage.
Open Sockets or End Point. Find a way to setup communication back from the service so that the service can call the client. This may be initiated by the client first telling the service where it is so it can call back. I forget the specifics, but WCF should be able to handle this out of the box for you. If you want something more generic you may need to roll your own.
Hope these ideas help.
As an option, use our MsgConnect (free with source) to send messages between services and controllers (crossplatform). Communication between services and controllers is possible both locally (via MMF or socket transport) and remotely (via socket transport).