I am trying to connect to some IBM MQ queues using C++. These queues have been defined under different manager queues in different servers. The idea is to connect to a VIP that will balance the workload pointing to each server.
The problem I have is I am using cmqc.h libraries, and in order to connect I have to make use of MQCONN or MQCONNX, for which I need the queue manager name, something that I cannot know as at the moment of the connection I don´t know which one will be used due to F5 balancer.
The code I am currently using as example is the following:
#include <cmqc.h>
#include <cmqxc.h>
#include <string.h>
#include <stdio.h>
#include <sstream>
#include <stdlib.h>
int main()
{
MQHCONN connectionHandle;
MQHOBJ m_SourceQueue;
MQLONG completionCode = 0;
MQLONG reasonCode = 0;
setenv("MQSERVER","SYSTEM.DEF.SVRCONN/TCP/<SERVER_IP_ADDRESS>(56245)",1);
MQCONN(<QUEUE_MANAGER_NAME>, &connectionHandle, &completionCode, &reasonCode);
if(MQCC_OK != completionCode)
{
printf ("%s \n", "Error");
printf ("%s %d \n", "Completion Code", completionCode);
printf ("%s %d \n", "Reason Code", reasonCode);
}
MQDISC(&connectionHandle, &completionCode, &reasonCode);
}
Does somebody have any idea how to connect to the queue when queue manager name is not available?
Based on the code you provide you can use NULL, or blanks, or even a * instead of a queue manager name.
For example:
MQCONN("", &connectionHandle, &completionCode, &reasonCode);
MQCONN(" ", &connectionHandle, &completionCode, &reasonCode);
MQCONN("*", &connectionHandle, &completionCode, &reasonCode);
Any of the above will connect to the queue manager listening on the host and port you specify in the MQSERVER environment variable.
MQCONN is documented in the IBM MQ Knowledge Center page MQCONN - Connect queue manager. Quoting a few things related to the queue manager name from this page:
If the name consists entirely of blanks, the name of the default queue
manager is used.
In the case of MQSERVER the default queue manager is the one listening on host and port connected to.
The page also has the following in the context of a CCDT but it works the same for MQSERVER:
If an all-blank name is specified, each client-connection channel with
an all-blank queue-manager name is tried until one is successful; in
this case there is no check against the actual name of the queue
manager.
Prefixing an asterisk to the connection name implies that the
application does not depend on connecting to a particular queue
manager in the group. Suitable applications are:
Applications that put messages but do not get messages.
Applications that put request messages and then get the reply messages from a temporary dynamic queue.
Unsuitable applications are ones that need to get messages from a
particular queue at a particular queue manager; such applications must
not prefix the name with an asterisk.
I would suggest that you instead use CCDT (Client Channel Definition Table) as it provides much more flexibility. MQSERVER can only provide the host, port, and channel name. A CCDT will allow you to configure many more options, for example TLS, security exits, max message length to name a few.
Related
I am trying to connect a C++ application (using MQCONNX) based on a PaaS IBM MQ client to two different queue managers, each one based on a different server (one in a PaaS server and the other one in a Unix server). Unfortunately I am not able to do it as I am getting a message when I try to connect to the second server saying that it is not possible as it is connected to the first queue manager. I am using two different MQHCONN connections, one for each queue manager, but the problem is still there.
I have taken a look into this link, but I still have some doubts, as for example, from which server should I copy the CCDT to the client?
https://www.ibm.com/support/pages/connecting-mq-clients-multiple-queue-managers-client-channel-definition-table-ccdt
Any help would be much appreciated, or even a quick sample of how to use CCDT, as right now I am completely stuck.
Many thanks in advance for any help.
Assuming Queue Manager 1 is called MQG1 and Queue Manager 2 is called MQG2 and these can be found using connection names of machine1.com(1701) and machine2.com(1702) respectively, and using channel names MQG1.SVRCONN and MQG2.SVRCONN respectively, you can create your CCDT, on your client application machine, thus:-
runmqsc -n
issue these commands into runmqsc:-
DEFINE CHANNEL(MQG1.SVRCONN) CHLTYPE(CLNTCONN) CONNAME('machine1.com(1701)') QMNAME(MQG1)
DEFINE CHANNEL(MQG2.SVRCONN) CHLTYPE(CLNTCONN) CONNAME('machine2.com(1702)') QMNAME(MQG2)
Then you can code your 2 x MQCONN (or MQCONNX if you need to specify any additional things on the connection) thus:-
#include <cmqc.h> /* Includes for MQI constants */
#include <cmqstrc.h> /* Convert MQRC into string */
MQHCONN hConn1 = MQHC_UNUSABLE_HCONN;
MQHCONN hConn2 = MQHC_UNUSABLE_HCONN;
MQCHAR QMName1[MQ_Q_MGR_NAME_LENGTH] = "MQG1";
MQCHAR QMName2[MQ_Q_MGR_NAME_LENGTH] = "MQG2";
MQLONG CompCode, Reason;
MQCONN(QMName1,
&hConn1,
&CompCode,
&Reason);
if (CompCode)
{
printf("MQCONN to %s failed with reason code %s (%d)\n", QMName1, MQRC_STR(Reason), Reason);
}
MQCONN(QMName2,
&hConn2,
&CompCode,
&Reason);
if (CompCode)
{
printf("MQCONN to %s failed with reason code %s (%d)\n", QMName2, MQRC_STR(Reason), Reason);
}
Take care with how you are linking your program. If you try to make two local connections, you will get a return code of MQRC_ANOTHER_Q_MGR_CONNECTED. Ensure you either link with the client library, set connection option MQCNO_CLIENT (which means you must use MQCONNX) or set the environment variable MQ_CONNECT_TYPE=CLIENT.
You might find the following blog post useful additional reading:-
IBM MQ Little Gem #30: MQ_CONNECT_TYPE
I'm trying to create application where multiple instances will run on same machine and they will communicate together via UDP via the same port.
I was reading many threads on StackOverflow about it that it should be possible.
Though, when I open connection from each application instance I can see that each instance sends a message but only first instance (if first is closed then second...) receives that message.
I'm using ACE library for the communication. Excerpt from code:
ACE_SOCK_Dgram_Mcast dgram;
ACE_INET_Addr *listenAddress = new ACE_INET_Addr(12345, ACE_LOCALHOST);
dgram.open(*listenAddress);
ACE_INET_Addr peer_address;
char buffer[1024];
dgram.send(buffer, 256);
while (true)
{
if (dgram.recv(buffer, 256, peer_address, 0, &receiveLoopTimeout) != -1)
{
std::cout << "Received" << std::endl;
}
}
I also found out that if I call "dgram.join(*listenAddress)" then I get error, code ENODEV from the first instance of the app.
I'm not sure I understand what you are trying to do... send a message multicast so multiple receivers get it, or allow multiple processes to receive on the same UDP port unicast... I'm guessing the former.
You're using the ACE_SOCK_Dgram_Mcast class but with unicast addressing and operations. So only one instance will receive that message.
Check the ACE_wrappers/tests/Multicast_Test.cpp for examples of how to send and receive multicast.
I was wondering, if it is possible to let one client communicate with multiple server at the same time. As far as I know, common browsers like for example firefox are doing exactly this.
The problem I have now is, that the client has to listen and wait for data from the server, rather then requesting it itself. It has to listen to multiple server at once. Is this even possible? What happens if the client is listening to server 1 and server 2 sends something? Is the package lost or will it be resend until the client communicates a successful receival? The protocol used is TCP.
edit: platform is Windows. Thanks for pointing this out Arunmu.
This is nothing different from regular socket programming using select/poll/epoll OR using thread-pool OR using process-per-connection OR whatever model that you know.
I can show you a rough pseudo-code on how to do it with epoll.
NOTE: None of my functions exist in C++, its just for explanation purpose. ANd I am ALSO assuming that you are on Linux, since you have mentioned nothing about the platform.
socket sd = connect("server.com", 8080);
sd.set_nonblocking(1);
epoll_event event;
event.data.fd = sd
epoll_ctl(ADD, event);
...
...
while (True) {
auto n = epoll_wait(events, 1);
for (int i : 1...n) {
if (events[i].data.fd == sd) // The socket added in epoll_ctl
{
std::thread(&Session::read_handler, rd_hndler_, sd); // Call the read in another thread or same thread
}
}
}
I hope you got the gist. In essence, think of server like a client and client like a server and you have your problem solved (kind of). Check out below link to know more about epoll
https://banu.com/blog/2/how-to-use-epoll-a-complete-example-in-c/
To see an fully functional server design using epoll, checkout:
https://github.com/arun11299/cpp-reactor-server/blob/master/epoll/reactor.cc
I am trying to write a program that sends basic text files from one computer to another using C++ over the internet (or a LAN). I was looking into Winsock but everything that I read made it seem like it was only for communication between a server and a client. I am not sure if this is what I am trying to do or if I am looking at a different problem.
EDIT: Thanks for the great answers guys. I kind of feel bad for having to choose a best one out of the lot.
A client-server architecture should be fine for sending files. The "server" is simply the program that starts first, and waits for the other (the client) to connect to it. Past there, there's not a lot of difference between the two. In a lot of cases, it's easiest to write the code so it automatically attempts to contact a server, and if it can't find one, it sets itself up as the server.
Also note that making things work across the internet with (particularly) NAT routers involved can make the code a little trickier. It's not all that tough if you pre-configure the firewall to allow the connection(s), but otherwise you typically end up using UPnP to establish the connection through the firewall. That can easily double the work compared to doing the job locally without NAT involved.
Here is an example of how to copy/transfer files using C/C++ in Linux.The server listens in port 8080. The client transmits a filename. The server receives the filename, open the file and sends its contents to the client. I intentionally used odd or small buffer sizes for illustrative purposes.
The server.c file:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>
#include <netinet/in.h>
#include <unistd.h>
#include <fcntl.h>
int main (int argc,char *argv[])
{
struct sockaddr_in p;
struct sockaddr_in q;
int z,s,t,x,n,b = sizeof(q);
char buf[23];
int fd;
s = socket(AF_INET,SOCK_STREAM,0);
bzero (&p,sizeof(p));
p.sin_family = AF_INET;
p.sin_addr.s_addr = INADDR_ANY;
p.sin_port = htons(8080);
bind (s,(struct sockaddr*)&p,sizeof(p));
listen(s,13);
while (1) {
t = accept (s,(struct sockaddr*)&q, &b);
n = read(t,buf,23);
buf[n] = 0;
printf("%s sent: ",buf);
fd = open (buf,O_RDONLY);
z = lseek(fd,0,SEEK_END);
lseek(fd,0,SEEK_SET);
x = 0;
do {
n = read (fd,buf,23);
write (t,buf,n);
x += n;
} while (x < z);
printf("%d/%d\n",x,z);
close(fd);
close(t);
}
}
The client.c file:
#include <stdio.h>
#include <string.h>
#include <netdb.h>
#include <unistd.h>
#include <fcntl.h>
void main (int argc, char *argv[])
{
int ret;
char buf[5];
int s,n,fd;
struct sockaddr_in p;
struct hostent *h;
char *str = argv[1];
fd = open (str,O_CREAT | O_WRONLY,S_IRUSR|S_IWUSR);
h = gethostbyname("127.0.0.1");
bzero(&p,sizeof(p));
p.sin_family = AF_INET;
p.sin_addr.s_addr = htonl(INADDR_ANY);
p.sin_addr.s_addr = ((struct in_addr*)(h->h_addr))->s_addr;
p.sin_port = htons(8080);
s = socket (AF_INET,SOCK_STREAM,0);
connect (s,(void*)&p,sizeof(p));
n = write (s,str,strlen(str));
int idx = 0;
do {
n = read (s,buf,5);
idx += n;
printf(".");
fflush(stdout);
write (fd,buf,n);
} while (n > 0);
close (fd);
close (s);
}
To compile:
Open terminal
gcc -o server server.c
gcc -o client client.c
Run the server as ./server. And then to copy rngoidiot.txt, run the client as ./client rngoidiot.txt and the file will be copied using TCP/IP. Simple combination ;-)
In short: Yes, sockets are the way to go.
"Server" and "client" in the sockets sense are generic terms - your system is running a variety of both at any given time. For example, your web browser operates as an HTTP client (where HTTP is a text-bounded mostly-synchronous protocol running over TCP/IP); Windows file sharing and remote desktop are "servers" that other systems connect into.
The distinction between server and client in the sockets sense (really in the TCP/IP sense) is that a "server" socket listens for incoming connections from remote systems (refer to MSDN or man pages on bind(), listen(), accept()) whereas a "client" socket creates outgoing connections to remote systems (connect()).
Beware that sockets programming can be a bit tricky. What you describe is a good learning exercise, but if you're trying to get something done quickly, you might look at existing tools such as netcat.
it seem like it was only for communication between a server and a client
So what? Make one computer (that is about to receive the file) the server. On that computer create a socket and make it listen for a connection on a port. Once a connection arrives, get the data according so some defined structure (see below)
The sender computer (the client, sort of) will connect to the other computer, and it knows the IP address and the port no. (The two must be known to the client for the connection). Once connection is made, it will send the data as a sequence of bytes to the server.
The structure:
The two computers that are communicating here must have a well defined structure that is known and accepted by both. The simplest structure will be:
|Length-Of-Data | Data ...... |
<-- 4 bytes---> <-- n bytes-->
Read the n from the first 4 bytes. The 4 bytes (n) here represent the length of the data and could be different, its your definition.
You could have many more 'fields' (depending on the functionality) for filename, file-type etc..
If you want to send files over internet, you have to use sockets, or better yet other high level library implemented with sockets.
In the TCP sockets terminology, there is no big difference between client and server: the communications is two way. The only difference is in who is listening for incoming connections (bind, listen, accept), and who is initiating the connection (open).
You mentioned Winsock, it means that you are working on Windows. Take a look into the Windows API, probably you can find some high level library that handles the file transfer (like a FTP or HTTP library).
Maybe doesn't fit your requirements, but you can also use a shared folder for a LAN and a folder synchronized by Dropbox for the Internet... then just use standard IO.
Speaking generally, any file transfer requires some sort of server/client connection. One computer needs to initiate a connection, and the other computer needs to be listening for the connection at the other end, and then take the actions it is instructed to by the first computer.
While you can certainly roll out your own client and server software using sockets, depending on what sorts of computers you want to transfer files between, it might make the most sense to leverage some existing client/server protocol. Some of the more popular possibilities include ssh, http, or ftp. I think C/C++ libraries should exist for all of these protocols.
Without more information I would be inclined to use ssh. Installing an ssh server shouldn't be too hard, so you'll only have to write the client software, and I think some pretty good open source libraries exist for that.
EDIT: libssh looks pretty good!
I am using libpcap to sniff traffic. I would like to do it on the currently active network device (e.g. one that has an assigned IP address, etc). What's the best way to do this? I'm assuming I would have to do the following:
pcap_findalldevs(&alldevs, errbuf)
to get all the network devices, then loop through and check which one is currently active.
Edit: The following function
(pcap_lookupnet(dev, &net, &mask, errbuf)
returns the network address and subnet mask for a network device. I ran some tests with the different ethernet adapters on my computer and it returns -1 when I call it on an adapter that is not connected to a network. Would this be the bulletproof way to get an active interface? Are there any edge cases it would miss?
the API pcap has for looking up interfaces conforming to some user defined rules is trivial. You could indeed use pcap_findalldevs() to interate over all suitable-to-use network devices or use pcap_lookupdev() to get the next network device that you can use with pcap. Defining what is the interface you want to use with your sniffer may be problematic (code wise) on systems with multiple network devices and you would want to define more explicit rules for choosing such an interface. Such rules are usually statically defined (like "the active interface with the default route installed"). However, you may have multiple default routes (think load balancing) and here you may either want to sniff on all of them or (for example) only on the ppp interface. So choosing the target interface I would say is a task to be resolved outside the sniffer rather than at runtime in the sniffer code.
For example:
If by "active interface" we understand the interface on which the default route is installed (i assume a linux system here):
ip route show 0.0.0.0/0 | awk ' { print $5 ; } ' | xargs ./sniffer
if you want to get the active interface which has the default route installed on from your sniffer code, you would rather use netlink(7) or proc(5) (/proc/net/route) than pcap's device lookup api but the complexity is high.
In conclusion, the interface lookup logic can be easily scripted into some wrapper program on any system and the result(s) passed as parameter(s) to your sniffer.
Why don't you capture on 'any' device (Pseudo-device that captures on all interfaces) ?
Any way, here is a little snippet that will help you find 'active' interfaces
#include <stdio.h>
#include <pcap.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
static void
dump_addresses (pcap_addr_t *addresses)
{
pcap_addr_t *addr = addresses;
printf("(");
while (addr) {
struct sockaddr_in *ip = (struct sockaddr_in *)addr->addr;
struct sockaddr_in *nm = (struct sockaddr_in *)addr->netmask;
if (ip && nm)
printf("%s/%s ",
inet_ntoa(ip->sin_addr), inet_ntoa(nm->sin_addr));
addr = addr->next;
}
printf(")");
}
static void
devs_dump (pcap_if_t *devs)
{
pcap_if_t *dev = devs;
while (dev) {
printf("dev: %s - %s - ",
dev->name, dev->description);
dump_addresses(dev->addresses);
printf("\n");
dev = dev->next;
}
}
int
main(int argc, char *argv[])
{
int r;
char errbuf[PCAP_ERRBUF_SIZE];
pcap_if_t *devs;
r = pcap_findalldevs (&devs, errbuf);
if (r) {
printf("Findalldevs: %d (%s)\n", r, errbuf);
return -1;
}
devs_dump(devs);
pcap_freealldevs (devs);
return 0;
}
I've been down this road several times before, and usually find myself falling back to adding a -i switch to allow the user to precisely identify the interface.
It makes your job simpler and avoids any edge conditions.
According to pcap_open_live (3):
DESCRIPTION
pcap_open_live() is used to obtain a packet capture handle to
look at packets on the network. device is a string that
specifies the network device to open; on Linux systems with
2.2 or later kernels, a device argument of "any" or NULL can
be used to capture packets from all interfaces.
But it seems it's deprecated now, you should use pcap_create(3)