Is it possible to have a boost asio udp client that is listening for messages on several ports at the same time? Or just listening for messages from any port?
For background (and because I am new to networking and probably not picking the best way to do this), essentially my problem is I have a main node kicking off processes on several other nodes in a cluster. When each child node finishes its process, it is to send it's results to another node that is waiting for results. I was thinking it would be easiest to simply do a UDP broadcast from each child node, with each child node broadcasting on a unique port, and the listener listening on all ports. Is there a better way to do this?
UDP sockets need to bind to a specific port if they have to receive incoming messages destined for that port. If you want to listen on a multiple of ports, then you will have to open multiple UDP sockets and bind them to all those ports. The bind method accepts the port number on which you wish to receive messages: http://www.boost.org/doc/libs/1_40_0/doc/html/boost_asio/reference/basic_datagram_socket/bind/overload1.html
Related
I have a synchronous server program using Linux TCP socket in C++. I'm using fork() to handle connections from different hosts. I would like to notify all of the child processes when specified action is performed by some of the connected hosts. What is the best way to propagate the information?
I have two processes. both listen to the same port.
This is UDP multicast so both use the socket option SO_REUSEADDR, and join the multicast group prior to bind().
When I send a message to the multicast group ip:port only one of the processes gets the message.
How can both of them get it?
Thanks.
Two process can listen at the same port. Although two sockets for connections can't be bound to the same IP address with same port.
You just add an entry for each process in your hosts file that points to a unique ip address.
Something like :
You bind process P1 to 127.0.0.1 port 8080 and P2 to 127.0.0.2 port 8080.
I don't think it's possible, and I think that sometimes it is a lot more coherent this way.
Maybe you should implement a receiver (which will listen to the port) which will distribute the messages to the other processes via inter-processes communication (pipes for instance).
Dear Stackoverflowers,
I am researching networking a bit and I decided I'd like to create a small and simple networking library with Winsock. (I am using Completion Ports and Overlapped IO though)
As I researched a bit I came to the following steps for a TCP Listener(Correct me if I am wrong):
Create a Listening Socket
Bind it to a port/IP
Listen on it
When a new connection is created, give a seperate Socket for that connection.
Listener continue's to listen, the specific connection is handled as needed.
EDIT: With a 'connection' from here I mean communication between the server and distinct clients.
Though for an UDP Listener we need to make use of WSARecvFrom which returns the IP address at the lpFrom parameter. Now I was wondering the following:
Is it better to make one UDP Socket listen to incoming connections on a specific port with WSARecvFrom and create new sockets for every specific connection? Or could I just use the UDP Socket itself with WSASendTo. Would that cause any performance penalties if one UDP Socket is used for for example 1000 connections? Or would it be the same or even better then creating/duplicating seperate Sockets for each different incoming connection?
Note: If multiple sockets are needed how would you handle sockets listening on the same port or could a client accept UDP from different ports?
Hope you guys can help!
Ps. Extra tips are always welcome!
Unlike TCP, UDP is connection-less, and as such you don't need to create separate sockets for each party. One UDP socket can handle everything. Bind it to a local IP/Port and call WSARecvFrom() once, and when it reports data to your IOCP you can process the data as needed (if another thread if needed) and then call WSARecvFrom() again. Each time new data arrives, you have to look at the reported lpFrom address to know the IP/Port of the sender. And yes, you can use the same UDP socket for sending data to each sender when needed.
I have 2 UDP sockets (SOCKET), one for sending and one for receiving on a Windows machine. They both work well, but the trouble is that a program that is receiving messages from my send socket replies to the same port which sent the message.
I know that if I don't bind the send socket, using sendto will pick an ephemeral port to send on.
I'd like to know if it is possible to any of the following, and if so, what is the recommended way to do it:
Bind both the send and receive sockets to a chosen port so that when the external program sends a message back it can be received.
Update the port to which the receive socket is bound in such a way as to receive on the port from which I last sent a message (not sure if this would create a race condition).
Some other correct method.
So far I have tried:
Not binding the send socket (it sends from some open port to the destination port). I can successfully receive messages on that port for as long as it doesn't change, but eventually it does change.
Binding both the send and receive sockets to a desired port. This creates the desired behaviour when I watch the packets using a sniffer, but the receive socket never receives the messages even though I see them being transmitted to the correct port and IP.
Packets are being received from more than one outside entity, and not guaranteed to be in any particular order.
Thank you in advance!
Looks like you are trying to use threads to separate sending and receiving data. I would question this approach, since UDP is so easy to handle in one thread. Nevertheless, you can just use the same socket from both threads if you want (see related question: Are parallel calls to send/recv on the same socket valid?). Just bind(2) it and, optionally, connect(2) it.
Basically I have an application that creates say 5 multicast sockets on the same interface and within the same application, each socket binds to a different multicast IP address/port. When any one of those sockets sends a message, the other 4 sockets within the application end up reading that message. Is this normal behavior?
This is happening in Ubuntu 11.10 using boost.asio and gcc 4.6.
It's normal in some operating systems ;-) You can turn it off with setsockopt() and the IP_MULTICAST_LOOP option.
Sounds strange to me. If you are using UDP, then you should only receive messages associated with the port number of the UDP socket. Of course, if you using multicast at the IP level, then the port number would not matter.
It is quite true (as per EJP) that loopback will cause programs to receive their own messages if loopback isn't disabled. However, the UDP port numbers still apply. A multicast UDP message sent to port x, should not be received by a socket listening for port y.