[Interest] QUdpSocket

[Igor Mironchik]

Hello,

Could anybody tell me if QUdpSocket after

QUdpSocket::bind( somePort, QUdpSocket::ShareAddress );

can be closed for some reasons and stopped for receiving new datagrams
(not from the application side, not from my code...)?

What can be the reason of such behavior (disconnection of bound QUdpSocket)?

Thank you.

P.S. Hope I'm clear in my question.

[Thiago Macieira]

Post by Igor Mironchik
Hello,
Could anybody tell me if QUdpSocket after
QUdpSocket::bind( somePort, QUdpSocket::ShareAddress );
can be closed for some reasons and stopped for receiving new datagrams
(not from the application side, not from my code...)?

Do you mean "can I call close() after bind()?"

Yes.

Post by Igor Mironchik
What can be the reason of such behavior (disconnection of bound QUdpSocket)?

What behaviour?

Post by Igor Mironchik
P.S. Hope I'm clear in my question.

Not really.

[Igor Mironchik]

Hi. What I afraid that happened.

Is situation possible that QUdpSocket in bound state can be somehow
disconnected (not from app's code) for any reason? I.e. something wrong
on the network, UDP socket can't work properly, something wrong in the
OS that leads to that UDP socket will not receive any datagrams? I ask
for regular situations that I need to check in my application...

Post by Thiago Macieira

Post by Igor Mironchik
Hello,
Could anybody tell me if QUdpSocket after
QUdpSocket::bind( somePort, QUdpSocket::ShareAddress );
can be closed for some reasons and stopped for receiving new datagrams
(not from the application side, not from my code...)?

Do you mean "can I call close() after bind()?"
Yes.

Post by Igor Mironchik
What can be the reason of such behavior (disconnection of bound QUdpSocket)?

What behaviour?

Post by Igor Mironchik
P.S. Hope I'm clear in my question.

Not really.

[Thiago Macieira]

Post by Igor Mironchik
Hi. What I afraid that happened.
Is situation possible that QUdpSocket in bound state can be somehow
disconnected (not from app's code) for any reason?

Yes. If you don't connect, it's disconnected. But disconnected UDP sockets can
still receive datagrams.

Post by Igor Mironchik
I.e. something wrong
on the network, UDP socket can't work properly, something wrong in the
OS that leads to that UDP socket will not receive any datagrams? I ask
for regular situations that I need to check in my application...

Firewall. As usual, check with wireshark that you are indeed receiving the
packets on your system.

[Konrad Rosenbaum]

hi,

Post by Igor Mironchik
Is situation possible that QUdpSocket in bound state can be somehow
disconnected (not from app's code) for any reason? I.e. something wrong
on the network, UDP socket can't work properly, something wrong in the
OS that leads to that UDP socket will not receive any datagrams? I ask
for regular situations that I need to check in my application...

Post by Igor Mironchik
QUdpSocket::bind( somePort, QUdpSocket::ShareAddress );

First off: UDP sockets are not connected - it is a connectionless protocol
in which every data packet is routed on its own.

Your above code means that the socket will listen on somePort of every
open interface and may share this with other programs listening on the
same port.

I hope you are checking the return code of bind! If this is false then the
socket is left in an undefined state. In this state you will not receive
any data (or be able to send anything) - you may or may not get errors
when you try.

If somePort is 0 then the OS will chose a port for you. The assignment is
somewhat unpredictable.

If somePort is <=1024 then the OS may block your bind attempt, because the
port is privileged.

If somePort is used exclusively by another program or the OS, then bind
will also fail.

SomePort may be blocked in your firewall. Or you may simply be mistaken
about the port number. You can check those cases with Wireshark.

The network interface on which you are hoping to receive data may be down.
You can check this with ipconfig (Windows) or ifconfig (Linux/Unix/Mac).

Your sending process might be sending to the wrong target address - it
needs to send to either one of your interface addresses or a multicast
group that your socket has joined.

If your sending process has bound its socket then the address must be
compatible with the target address (e.g. it is impossible to send from
127.0.0.1 to 192.168.1.2 or from a multicast address). You can check
bindings with netstat, you can check whether packets are sent with
Wireshark.

Your sending process and your receiving process might use different
protocols (IPv4 vs. IPv6) if you messed up some settings. You can find out
with netstat and Wireshark.

Good luck with your diagnosis!

Konrad

[Igor Mironchik]

Hi,

Post by Konrad Rosenbaum
First off: UDP sockets are not connected - it is a connectionless protocol
in which every data packet is routed on its own.

Sure, I know it, thanks.

Post by Konrad Rosenbaum
Your above code means that the socket will listen on somePort of every
open interface and may share this with other programs listening on the
same port.
I hope you are checking the return code of bind! If this is false then the
socket is left in an undefined state. In this state you will not receive
any data (or be able to send anything) - you may or may not get errors
when you try.

Sure, I check codes. My IPC works. I just want to know should I care
about something with UDP or I can just do bind() and process pending
datagrams, and don't worry about something additional in my code?! Thanks.

Post by Konrad Rosenbaum
If somePort is 0 then the OS will chose a port for you. The assignment is
somewhat unpredictable.
If somePort is <=1024 then the OS may block your bind attempt, because the
port is privileged.
If somePort is used exclusively by another program or the OS, then bind
will also fail.
SomePort may be blocked in your firewall. Or you may simply be mistaken
about the port number. You can check those cases with Wireshark.
The network interface on which you are hoping to receive data may be down.
You can check this with ipconfig (Windows) or ifconfig (Linux/Unix/Mac).
Your sending process might be sending to the wrong target address - it
needs to send to either one of your interface addresses or a multicast
group that your socket has joined.
If your sending process has bound its socket then the address must be
compatible with the target address (e.g. it is impossible to send from
127.0.0.1 to 192.168.1.2 or from a multicast address). You can check
bindings with netstat, you can check whether packets are sent with
Wireshark.
Your sending process and your receiving process might use different
protocols (IPv4 vs. IPv6) if you messed up some settings. You can find out
with netstat and Wireshark.
Good luck with your diagnosis!
Konrad
_______________________________________________
Interest mailing list
http://lists.qt-project.org/mailman/listinfo/interest

[Konrad Rosenbaum]

Hi,

Post by Igor Mironchik

Post by Konrad Rosenbaum
Your above code means that the socket will listen on somePort of every
open interface and may share this with other programs listening on the
same port.
I hope you are checking the return code of bind! If this is false then the
socket is left in an undefined state. In this state you will not receive
any data (or be able to send anything) - you may or may not get errors
when you try.

Sure, I check codes. My IPC works. I just want to know should I care
about something with UDP or I can just do bind() and process pending
datagrams, and don't worry about something additional in my code?! Thanks.

I'm not sure what exactly your question is. So I'll continue to guess...

After a successful bind your UDP socket is ready to communicate - you can
receive and send packets, no need for any other initialization calls.


Konrad

[Francisco Gonzalez]

Hi,
Sure, I check codes. My IPC works. I just want to know should I care about
something with UDP or I can just do bind() and process pending datagrams,
and don't worry about something additional in my code?! Thanks.
QUdpSocket inherits "*error

<http://doc.qt.io/qt-5/qabstractsocket.html#error-1>*(QAbstractSocket::SocketError
*socketError*)" signal.
Some of the possible errors are applicable to Udp Socket.