Unsolved Impossible to bind QTcpSocket again after connection error
-
@Karlor said in Impossible to bind QTcpSocket again after connection error:
Why binding is failing after a fixed network cable? Is there any solution to fix binding?
Use
QUdpSocket
. You bind UDP sockets (as UDP is a conectionless protocol) and you connect TCP sockets to your known host (as the TCP sockets are connection-oriented), so unless I'm missing something you're just doing it wrong.Either use
bind()
withQUdpSocket
orconnectToHost
withQTcpSocket
. -
@Karlor
Like @kshegunov says, for TCP connections you will usebind()
,listen()
&accept()
only at the server side, andconnect()
only at the client side. I don't know about his UDP suggestion, that's a different matter. -
Do you mean the OS' functions in that last post, because I meant Qt's API.
-
@kshegunov
Is that addressed to me?In my reply I was attempting to back up your previous reply. Perhaps I gave too much (non-Qt) information. I haven't even looked up what Qt names its functions, sounds like with
QTcpSocket
you usebind()
only at server side andconnectToHost()
only at client side. -
@JonB said in Impossible to bind QTcpSocket again after connection error:
Is that addressed to me?
Yep, says to whom I replied rightwards of the post's date.
In my reply I was attempting to back up your previous reply. Perhaps I gave too much (non-Qt) information.
Mhm, I got that. I Just wondered whether the functions you mentioned you meant as the C functions one'd usually use for networking.
-
@kshegunov
Yes, indeed they are the C functions I used years ago, and still recall fondly :) They were native under UNIX, and provided under same names by WinSock. IMHO, if you want to get anything done and still understand what's going on underneath all the obfuscation layers C++ attempts to pile on, you need to know what it's ultimately calling at the OS level, because that's all the C++ still has available to it ;-) -
@JonB said in Impossible to bind QTcpSocket again after connection error:
all the obfuscation layers C++
We call them abstraction layers, you see. ;)
-
Thank you for your answers.
I have realized I have missed maybe something important. On client side computers are installed multiple network interfaces.
I have been informed that the binding in the client side part of our software is implemented for purpose to connect with appropriate network interface to connect to the right server and must use
QTcpSocket::bind()
withQAbstractSocket::ReuseAddressHint
.But even with multiple network interfaces I think @kshegunov's answer is still right. I have tested connections to servers without binding and everything works fine.
I would like to ask to some subquestions to this topic.
- I am confused by Qt documentation for QAbstractSocket::bind() where is written
For TCP sockets, this function may be used to specify which interface to use for an outgoing connection, which is useful in case of multiple network interfaces.
Even with multiple network interfaces the binding is not mandatory and only
connectToHost()
to IP server address should be sufficient, isn't it?- Is it true that binding in mode
QAbstractSocket::ReuseAddressHint
in calling
socket.bind(bindAddress, 0, QAbstractSocket::ReuseAddressHint)
is useless, because it will use any available port (the second argument is 0) and reusing has no effect in this case?
-
@Karlor said in Impossible to bind QTcpSocket again after connection error:
Even with multiple network interfaces the binding is not mandatory and only connectToHost() to IP server address should be sufficient, isn't it?
If it connects then it should be sufficient. I haven't had this particular case, however I imagine the
bind()
is required to specify your outgoing address (a.k.a. interface), so you're using the correct network. If there isn't ambiguity then I supposeconnectToHost
would do on its own.Is it true that binding in mode QAbstractSocket::ReuseAddressHint in calling
[snippet]That line looks correct, yes.
-
Fortunately in our case the connection via
QTcpSocket::connectToHost()
without needQTcpSocket::bind()
is sufficient. However, this may change in the future, and it may need to specify the outgoing network interface, so the problem of stacked binding ofQTcpSocket
will be there again.I found hypothetic scenario in which things might go worse if an error occurred. Imagine having two network interfaces labeled as N1 and N2. N1 is disconnected from the network. If the user accidentally decides to bind via
QTcpSocket::bind()
to N1, the connection fails. Changing the connection to N2 is now impossible. I guess it is impossible becauseQTcpSocket
is still bounded to N1, so rebind to N2 fails and the connection to N2 is not possible.Do you know how to reset
QTcpSocket
to useQTcpSocket::bind()
again?