* Check whether we received/can send some data from/to the STUN server and * when that's the case handle it appropriately. */
| 129 | * when that's the case handle it appropriately. |
| 130 | */ |
| 131 | void ClientNetworkStunSocketHandler::SendReceive() |
| 132 | { |
| 133 | if (this->sock == INVALID_SOCKET) return; |
| 134 | |
| 135 | /* We never attempt to receive anything on a STUN socket. After |
| 136 | * connecting a STUN connection, the local address will be reused to |
| 137 | * to establish the connection with the real server. If we would be to |
| 138 | * read this socket, some OSes get confused and deliver us packets meant |
| 139 | * for the real connection. It appears most OSes play best when we simply |
| 140 | * never attempt to read it to start with (and the packets will remain |
| 141 | * available on the other socket). |
| 142 | * Protocol-wise, the STUN server will never send any packet back anyway. */ |
| 143 | |
| 144 | this->CanSendReceive(); |
| 145 | if (this->SendPackets() == SPS_ALL_SENT && !this->sent_result) { |
| 146 | /* We delay giving the GC the result this long, as to make sure we |
| 147 | * have sent the STUN packet first. This means the GC is more likely |
| 148 | * to have the result ready by the time our StunResult() packet |
| 149 | * arrives. */ |
| 150 | this->sent_result = true; |
| 151 | _network_coordinator_client.StunResult(this->token, this->family, true); |
| 152 | } |
| 153 | } |
no test coverage detected