UDP : How to send a response to a client
-
wrote on 30 Dec 2011, 10:18 last edited by
Hi
I want to write a UDP server which will listen for requests coming from various UDP clients. After receiving a request it will send a response to that client. How can I do that in Qt?
I am binding a QUdpSocket instance to a specific port to listen for client requests. As a resut when a request arrives the readyread signal is emitted. I can then read the request in the corresponding slot method. But now to send a response I need to know client's address and port. How can I get that?
-
wrote on 30 Dec 2011, 10:31 last edited by
AFAIK it would be better to make the request through TCP/IP since you know it will be received.
UDP is more a one transmission without checking of reception on the other end ("see also":http://en.wikipedia.org/wiki/User_Datagram_Protocol#Comparison_of_UDP_and_TCP ). -
wrote on 30 Dec 2011, 10:37 last edited by
UDP has its uses, and without knowing the use case one cannot advise to use TCP instead of UDP.
The point of UDP is that you basically just send of a bit of information to another IP at a certain port, and that's it. There is no connection, so also no back channel. If you want to reply, your client will also need to be listening on a certain port, and your server can send the UDP response back to that port. You could choose a fixed port to listen on, or you could make the client send a port number it will be listening on in one of the messages to the server.
-
wrote on 30 Dec 2011, 10:37 last edited by
[quote author="koahnig" date="1325241071"]AFAIK it would be better to make the request through TCP/IP since you know it will be received.
UDP is more a one transmission without checking of reception on the other end ("see also":http://en.wikipedia.org/wiki/User_Datagram_Protocol#Comparison_of_UDP_and_TCP ). [/quote]The client doesn't know that the request will be received for sure. Similarly, the server also doesn't know that a client request will arrive. But even if a single client request arrives at server, then the server must send a response back to the client. This is why I want to know if there is any way to get the client address and port.
-
wrote on 30 Dec 2011, 10:45 last edited by
[quote author="sayem.bd" date="1325241455"]
The client doesn't know that the request will be received for sure. Similarly, the server also doesn't know that a client request will arrive. But even if a single client request arrives at server, then the server must send a response back to the client. This is why I want to know if there is any way to get the client address and port.[/quote]Well, there are apparently these "access methods":http://developer.qt.nokia.com/doc/qt-4.8/qabstractsocket.html#peerAddress (also for local address and ports) available.
@Andre I wonder if it is a good strategy to use UDP instead of TCP/IP for forward and backward communication. At the day's end you might have to establish certain checks simulating what is already part of TCP/IP.
-
wrote on 30 Dec 2011, 10:48 last edited by
True enough, it may be better to use TCP, but without more information on the use case, that is not possible to decide.
-
wrote on 30 Dec 2011, 10:50 last edited by
Thanks Andre, your answer explained a lot of things.
-
wrote on 30 Dec 2011, 10:55 last edited by
[quote author="Andre" date="1325242094"]True enough, it may be better to use TCP, but without more information on the use case, that is not possible to decide.[/quote]
You are right there might be justifications for UDP in certain use cases.
-
wrote on 30 Dec 2011, 10:55 last edited by
"QUdpSocket::readDatagram() ":/doc/qt-4.8/qudpsocket.html#readDatagram takes optional pointers to a [[Doc:QHostAddress]] for the address and a quint for the port.
bq. Receives a datagram no larger than maxSize bytes and stores it in data. The sender's host address and port is stored in *address and *port (unless the pointers are 0).
Use it to send your data back to the sender.
In Qt, using [[Doc:QUdpSocket]] you can sort of connect between the server and the client and use [[Doc:QIODevice]]'s read() and write() methods. This is not a real connection like in using TCP, but kind of a "virtual connection".
2/9