[Windows] First QUdpSocket::bind blocks for three seconds

[aha_1980]

Update: filtering the addresses starting with "169.254" did not help. It now stucks three seconds on my primary "192.168.16.56" IP address.

Thanks also @J-Hilk, the order does not seem to matter...

[dheerendra]

How about checking directly with calls like socket(...) & bind(..) call without using Qt ?

[dheerendra]

Any reason you are calling bind(..) each time for each interfaces ? You can also try simple with passing QHostAddress::AnyIPv4 with just one bind call. This will allows the packet to coming from any interface.

[aha_1980]

@dheerendra

How about checking directly with calls like socket(...) & bind(..) call without using Qt ?

Have not tried yet, and probably will not have time for that soon.

Any reason you are calling bind(..) each time for each interfaces ?

Because I send a datagram on each interface and listen for answers.

You can also try simple with passing QHostAddress::AnyIPv4 with just one bind call.

Doesn't help. The first bind() call blocks, no matter which address is given. Even the overload that takes no parameters blocks.

Every next bind() is very fast. I think @Christian-Ehrlicher is right that it is some kind of network timeout. Not sure if DNS is involved here, but I will check more deeply when I installed Wireshark on that machine.

[dheerendra]

Not sure if DNS is involved here,

DNS is not involved for bind. Only ARP can play role here. It is to get the MAC address corresponding to IP address. For the bind even this should not kick in. Even ARP will come into picture only if you start data transfer. Actually internally bind is not doing anything other than filling the Socket DataStructure with Source IP and Source Port#. If you are interested i can give you vanilla socket program to check on this.

[JonB]

@aha_1980
You state that the first bind() is what takes the extra time. However, your debug output prints start before it does anything and then does not print anything till after the first bind() has completed, and state that must be what is taking the time.

I think you should determine whether that time is actually during the QNetworkInterface::allAddresses() call, while it gathers all addresses. Pull that into its own variable and time just that part. Is that actually where the 3 seconds is spent?

[aha_1980]

@JonB

Please read the topic title from the beginning :)

I think you should determine whether that time is actually during the QNetworkInterface::allAddresses() call, while it gathers all addresses. Pull that into its own variable and time just that part. Is that actually where the 3 seconds is spent?

I already expected that comment - but it's valid. No, it's really the bind() that takes the time. I already split that up to gather the addresses and bind each interface separate in a QTimers timeout, but it does not help.

Fact is, the first bind() takes ages and blocks the GUI.

[aha_1980]

@dheerendra Yes, I'd try a vanilla program if you got one.

I just will not get around to do this today, as I'm starting to Qt Summit in a few hours. So testing will have to wait at least until friday.

[dheerendra]

Please share an email on the chat message. I will drop you an email with the program.

[aha_1980]

Just as short interim report: A simple Windows winsock2 API program binds immediately. So it looks like I have to dig deeper, I just don't have the time for that right now. I'll come back to this problem later.

Thanks for all your help so far.

[JonB]

@aha_1980
Just as a short interim suggestion: As you are an expert Qt-er, if you're set up to run your program profiled would that immediately tell you where the extra time is being spent?

[aha_1980]

@JonB probably. But nevertheless I'd need to dig into Qt sources. Also, this problem is one Windows (I'm not even sure if it is machine specific), and I dont have a debug/profile Qt setup there.

Otherwise I'd not asked ;)

[Light Chaos]

@aha_1980 Try this: setProxy(QNetworkProxy::NoProxy)