My PC has several network cards and I'm trying to receive UDP data from several broadcast devices. Each device is isolated on a dedicated network and I'm trying to read UDP data from multiple devices at the same time. I'm using Boost version 1.67. Let's pretend in this post that I want to get data from one only specific device, so I want to bind on a local network interface.
On Windows the following code works, but on my Ubuntu 16.04 64bits machine it does not. Indeed, if I bind on one specific local IP address (192.168.1.1 in this example) I do not get any data. But if I use the ANY "0.0.0.0" address then I get what I want. Except that in that case I don't know where it comes from. It could be received by any network card!
Is it normal behavior ? Or do I need to read the sender_endpoint to know that information on Linux and filter afterwards?
#include <iostream>
#include <boost/array.hpp>
#include <boost/asio.hpp>
using boost::asio::ip::udp;
int main(int argc, char* argv[])
{
try
{
boost::asio::io_context io_context;
// Setup UDP Socket
udp::socket socket(io_context);
socket.open(udp::v4());
// Bind to specific network card and chosen port
socket.bind(udp::endpoint(boost::asio::ip::address::from_string("192.168.1.1"), 2368));
// Prepare to receive data
boost::array<char, 128> recv_buf;
udp::endpoint sender_endpoint;
size_t len = socket.receive_from(boost::asio::buffer(recv_buf), sender_endpoint);
// Write data to std output
std::cout.write(recv_buf.data(), len);
}
catch (std::exception& e)
{
std::cerr << e.what() << std::endl;
}
return 0;
}
A little late but others might come to this as well as I have been attempting this with Boost and trying to figure out how it works. From reviewing this question: Fail to listen to UDP Port with boost::asio I went to this page: https://forums.codeguru.com/showthread.php?504427-boost-asio-receive-on-linux and it turns out on Linux that you need to bind to the "any address" in order to receive broadcast packets. So you would set this up as your receiving endpoint:
udp::endpoint(boost::asio::ip::address_v4::any(), port)
And then yes you would need to filter on the sender information. Seems a bit odd but seems to be the way Linux interfaces handle broadcasts.
Related
I am practicing a bit with sockets and UDP client-server architecture and, referring to some examples available on the web, I have implemented a very simple UDP server using C and a UDP client class using C++.
Briefly speaking, the current implementation let the server listen for incoming messages and transmit back the same packet to client.
It seems to work fine if client makes sequential requests.
Here is a brief explanatory example:
#include "UDPClient.h"
int main(int argc, char* argv[]) {
UDPClient testClient;
testClient.initSockets(1501, "127.0.0.1", 1500);
for (int i = 0; i < 10; i++) {
testClient.notifyEntry();
testClient.notifyExit();
}
return 0;
}
Since client actually should share with server more informations at the same time, I tested the same code block starting new threads:
#include <thread>
#include "UDPClient.h"
int main(int argc, char* argv[]) {
UDPClient testClient;
std::thread thrdOne, thrdTwo;
testClient.initSockets(1501, "127.0.0.1", 1500);
for (int i = 0; i < 10; i++) {
thrdOne = std::thread(UDPClient::notifyEntry, std::ref(testClient));
thrdTwo = std::thread(UDPClient::notifyExit, std::ref(testClient));
}
return 0;
}
As you can see, notifyEntry and notifyExit have been made static and currently need a reference to a class instance to work properly.
Furthermore, inside their function body I have added also a little code block in order to check if, since the server sends back the same content, the sent message is equal to the received one.
Here is a explanatory example:
void UDPClient::notifyEntry(UDPClient& inst) {
char buffer = "E"
inst.sendPacket(buffer); // sendto...
inst.receivePacket(buffer); // recvfrom...
if (!(buffer == 'E') ){
std::string e = "Buffer should be E but it is ";
e.append(buffer);
throw UDPClientException(e);
}
}
Using multithreading often happens that the above mentioned check throws exception, because the buffer actually contains another char (the one sent by notifyExit).
Taking this information into account, I would like to ask you:
this happens because the recvfrom of a thread can catch also the response of a request from another one, being the socket instantiated only a single bound socket?
if yes, should I instantiate more than a single socket (for instance, each one usable for only a single type of messages, that is one for notifyEntry and one for notifyExit)? Does multithreading on server for response only not solve the issue mentioned anyway?
this happens because the recvfrom of a thread can catch also the
response of a request from another one, being the socket instantiated
only a single bound socket?
That's very likely -- if you have multiple threads calling recvfrom() on the same UDP socket, then it will be indeterminate/unpredictable which thread receives which incoming UDP packet.
if yes, should I instantiate more than a single socket (for instance,
each one usable for only a single type of messages, that is one for
notifyEntry and one for notifyExit)?
Yes, I'd recommend having each thread create its own private UDP socket and bind() its socket to its own separate port (e.g. by passing 0 as the port number to bind()); that way each thread can be sure to receive only its own responses and not get confused by responses that were intended for other threads. (Note that you'll also want to code your server to send its replies back to the IP address and port that was reported by the recvfrom() call, rather than sending reply packets back to a hard-coded port number)
Does multithreading on server for response only not solve the issue
mentioned anyway?
No, the correct handling of UDP packets (or not) is a separate issue that is independent of whether the server is single-threaded or multi-threaded.
This is a simple problem, but I can't seem to figure out what I am doing wrong. I am attempting to read data sent to a port on a client using Boost and I have the following code which sets up 1) the UDP client, 2) a buffer for reading to and 3) an attempt to read from the socket:
// Set up the socket to read UDP packets on port 10114
boost::asio::io_service io_service;
udp::endpoint endpoint_(udp::v4(), 10114);
udp::socket socket(io_service, endpoint_);
// Data coming across will be 8 bytes per packet
boost::array<char, 8> recv_buf;
// Read data available from port
size_t len = socket.receive_from(
boost::asio::buffer(recv_buf,8), endpoint_);
cout.write(recv_buf.data(), len);
The problem is that the recieve_from function never returns. The server is running on another computer and generating data continuously. I can see traffic on this port on the local computer using Wireshark. So, what am I doing wrong here?
So, it turns out that I need to listen on that port for connections coming from anywhere. As such, the endpoint needs to be setup as
boost::asio::ip::udp::endpoint endpoint_(boost::asio::ip::address::from_string("0.0.0.0"), 10114);
Using this setup, I get the data back that I expect. And fyi, 0.0.0.0 is the same as INADDR_ANY.
I have a UDP server using the following code:
void initialize()
{
connect(&_udpSocket, SIGNAL(readyRead()), this, SLOT(onUdpDatagram()));
_udpSocket.bind(QHostAddress::Any, 28283);
}
void onUdpDatagram()
{
qDebug() << "udp packet received!";
_udpSocket.write("Hello");
}
Unfortunately when a UDP packet is received, I have the following error in the log:
QIODevice::write: device not open
How can I make the UDP socket writable? I tried to create another socket for the answer that connect to the sender address and port but the sending won't use the 28283 port anymore...
Any idea?
For info: I'm using Qt 5.2.1 on MacOS 10.9
UDP is not a connection-based protocol. You don't get a separate socket for each peer, instead there's one socket for all communication on a single port.
Therefore, there's some extra effort needed to reply to an incoming UDP packet. You need to retrieve the sender address from the datagram you received, and send back to that same address. In the sockets API this is done by using recvfrom and sendto functions instead of recv (or read) and send (or write) -- the latter are designed for connected sockets like you use with TCP.
You didn't show the declaration (really, the type) for your _udpSocket variable, so I'm assuming that you are using a QUdpSocket. In that case, it looks like you will want to use the readDatagram and writeDatagram functions, which like recvfrom and sendto, have an additional parameter for the peer address (actually, it's a pair, one for the IP address, one for the port).
Here's what the Qt documentation says about that:
The most common way to use this class is to bind to an address and port using bind(), then call writeDatagram() and readDatagram() to transfer data. If you want to use the standard QIODevice functions read(), readLine(), write(), etc., you must first connect the socket directly to a peer by calling connectToHost().
Coincidentally, this warning was introduced by me in Qt upstream:
QIODevice::write: device not open
It should be pretty clear unlike before the introduction of this, namely: you have forgotten to connect to the host with your udp socket. You cannot expect it to write and/or read if it is not even open and/or connected. See the documentation for details:
If you want to use the standard QIODevice functions read(), readLine(), write(), etc., you must first connect the socket directly to a peer by calling connectToHost().
You have to do something like this somewhere in your code:
_udpSocket.connectToHost(myHostAddress, 28283, ReadWrite, AnyIPProtocol);
The last two parameters can be skipped as they are the default. As you can read from the documentation, this method call will open the socket for you, too, which is necessary to get done for QIODevice read and write operations.
That being said, you really should not neglect error checking in your code as it currently seems to stand. It will be difficult to find the issues this way.
Also, it is ice on the cake, but I would encourage you to start using the "new" signal-slot syntax, which is not so new, but much more modern and handier:
void initialize()
{
connect(&_udpSocket, &QUdpSocket::connected, [&_udpSocket]() {
connect(&_udpSocket, &QUdpSocket::readyRead, [&_udpSocket]() {
qDebug() << "udp packet received!";
if (_udpSocket.write("Hello") != 6)
qDebug() << "Failed to write:" << _udpSocket.errorString();
});
});
connect(&_udpSocket, &QUdpSocket::error, [&_udpSocket]() {
qDebug() << "Error occured:" << _udpSocket.errorString();
});
_udpSocket.connectToHost(myHostAddress, 28283, ReadWrite, AnyIPProtocol);
}
I have just started using the Poco library. I am having issues getting two computers to communicate using Poco's DatagramSocket objects. Specifically, the receiveBytes function does not seem to return (despite running Wireshark and seeing that the UDP packets I am sending ARE arriving at the destination machine). I assume I am omitting something simple and this is all due to a dumb mistake on my part. I have compiled Poco 1.4.3p1 on Windows 7 using Visual Studio Express 2010. Below are code snippets showing how I am trying to use Poco. Any advise would be appreciated.
Sending
#include "Poco\Net\DatagramSocket.h"
#include "Serializer.h" //A library used for serializing data
int main()
{
Poco::Net::SocketAddress remoteAddr("192.168.1.140", 5678); //The IP address of the remote (receiving) machine
Poco::Net::DatagramSocket mSock; //We make our socket (its not connected currently)
mSock.connect(remoteAddr); //Sends/Receives are restricted to the inputted IPAddress and port
unsigned char float_bytes[4];
FloatToBin(1234.5678, float_bytes); //Serializing the float and storing it in float_bytes
mSock.sendBytes((void*)float_bytes, 4); //Bytes AWAY!
return 0;
}
Receiving (where I am having issues)
#include "Poco\Net\DatagramSocket.h"
#include "Poco\Net\SocketAddress.h"
#include "Serializer.h"
#include <iostream>
int main()
{
Poco::Net::SocketAddress remoteAddr("192.168.1.116", 5678); //The IP address of the remote (sending) machine
Poco::Net::DatagramSocket mSock; //We make our socket (its not connected currently)
mSock.connect(remoteAddr); //Sends/Receives are restricted to the inputted IPAddress and port
//Now lets try to get some datas
std::cout << "Waiting for float" << std::endl;
unsigned char float_bytes[4];
mSock.receiveBytes((void*)float_bytes, 4); //The code is stuck here waiting for a packet. It never returns...
//Finally, lets convert it to a float and print to the screen
float net_float;
BinToFloat(float_bytes, &net_float); //Converting the binary data to a float and storing it in net_float
std::cout << net_float << std::endl;
system("PAUSE");
return 0;
}
Thank you for your time.
The POCO sockets are modeled on the Berkeley sockets. You should read a basic tutorial on the Berkeley socket API, this will make it easier to understand the POCO OOP socket abstractions.
You cannot connect() on both client and server. You connect() on the client only. With UDP, connect() is optional, and can be skipped (then you have to use sendTo() instead of SendBytes()).
On the server, either you bind() on the wildcard IP address (meaning: will then receive on all the available network interfaces on the host), or to a specific IP address (meaning: will then receive only on that IP address).
Looking at your receiver/server code, it seems you want to filter on the address of the remote client. You cannot do it with connect(), you have to read with receiveFrom(buffer, length, address) and then filter yourself on "address".
Security-wise, be careful with the assumptions you make with the source address of the UDP packets you receive. Spoofing a UDP packet is trivial. Said in another way: do not make authentication or authorization decisions based on an IP address (or on anything not secured by proper cryptography).
The POCO presentation http://pocoproject.org/slides/200-Network.pdf explains, with code snippets, how to do network programming with POCO. See slides 15, 16 for DatagramSocket. Note that on slide 15 there is a typo, replace msg.data(), msg.size() with syslogMsg.data(), syslogMsg.size() to compile :-)
Have a look also at the "poco/net/samples" directory for short examples that show also the best practices in using POCO.
I want to verify the connection status before performing read/write operations.
Is there a way to make an isConnect() method?
I saw this, but it seems "ugly".
I have tested is_open() function as well, but it doesn't have the expected behavior.
TCP is meant to be robust in the face of a harsh network; even though TCP provides what looks like a persistent end-to-end connection, it's all just a lie, each packet is really just a unique, unreliable datagram.
The connections are really just virtual conduits created with a little state tracked at each end of the connection (Source and destination ports and addresses, and local socket). The network stack uses this state to know which process to give each incoming packet to and what state to put in the header of each outgoing packet.
Because of the underlying — inherently connectionless and unreliable — nature of the network, the stack will only report a severed connection when the remote end sends a FIN packet to close the connection, or if it doesn't receive an ACK response to a sent packet (after a timeout and a couple retries).
Because of the asynchronous nature of asio, the easiest way to be notified of a graceful disconnection is to have an outstanding async_read which will return error::eof immediately when the connection is closed. But this alone still leaves the possibility of other issues like half-open connections and network issues going undetected.
The most effectively way to work around unexpected connection interruption is to use some sort of keep-alive or ping. This occasional attempt to transfer data over the connection will allow expedient detection of an unintentionally severed connection.
The TCP protocol actually has a built-in keep-alive mechanism which can be configured in asio using asio::tcp::socket::keep_alive. The nice thing about TCP keep-alive is that it's transparent to the user-mode application, and only the peers interested in keep-alive need configure it. The downside is that you need OS level access/knowledge to configure the timeout parameters, they're unfortunately not exposed via a simple socket option and usually have default timeout values that are quite large (7200 seconds on Linux).
Probably the most common method of keep-alive is to implement it at the application layer, where the application has a special noop or ping message and does nothing but respond when tickled. This method gives you the most flexibility in implementing a keep-alive strategy.
TCP promises to watch for dropped packets -- retrying as appropriate -- to give you a reliable connection, for some definition of reliable. Of course TCP can't handle cases where the server crashes, or your Ethernet cable falls out or something similar occurs. Additionally, knowing that your TCP connection is up doesn't necessarily mean that a protocol that will go over the TCP connection is ready (eg., your HTTP webserver or your FTP server may be in some broken state).
If you know the protocol being sent over TCP then there is probably a way in that protocol to tell you if things are in good shape (for HTTP it would be a HEAD request)
If you are sure that the remote socket has not sent anything (e.g. because you haven't sent a request to it yet), then you can set your local socket to a non blocking mode and try to read one or more bytes from it.
Given that the server hasn't sent anything, you'll either get a asio::error::would_block or some other error. If former, your local socket has not yet detected a disconnection. If latter, your socket has been closed.
Here is an example code:
#include <iostream>
#include <boost/asio.hpp>
#include <boost/asio/spawn.hpp>
#include <boost/asio/steady_timer.hpp>
using namespace std;
using namespace boost;
using tcp = asio::ip::tcp;
template<class Duration>
void async_sleep(asio::io_service& ios, Duration d, asio::yield_context yield)
{
auto timer = asio::steady_timer(ios);
timer.expires_from_now(d);
timer.async_wait(yield);
}
int main()
{
asio::io_service ios;
tcp::acceptor acceptor(ios, tcp::endpoint(tcp::v4(), 0));
boost::asio::spawn(ios, [&](boost::asio::yield_context yield) {
tcp::socket s(ios);
acceptor.async_accept(s, yield);
// Keep the socket from going out of scope for 5 seconds.
async_sleep(ios, chrono::seconds(5), yield);
});
boost::asio::spawn(ios, [&](boost::asio::yield_context yield) {
tcp::socket s(ios);
s.async_connect(acceptor.local_endpoint(), yield);
// This is essential to make the `read_some` function not block.
s.non_blocking(true);
while (true) {
system::error_code ec;
char c;
// Unfortunately, this only works when the buffer has non
// zero size (tested on Ubuntu 16.04).
s.read_some(asio::mutable_buffer(&c, 1), ec);
if (ec && ec != asio::error::would_block) break;
cerr << "Socket is still connected" << endl;
async_sleep(ios, chrono::seconds(1), yield);
}
cerr << "Socket is closed" << endl;
});
ios.run();
}
And the output:
Socket is still connected
Socket is still connected
Socket is still connected
Socket is still connected
Socket is still connected
Socket is closed
Tested on:
Ubuntu: 16.04
Kernel: 4.15.0-36-generic
Boost: 1.67
Though, I don't know whether or not this behavior depends on any of those versions.
you can send a dummy byte on a socket and see if it will return an error.