What does it mean for a connect() call to be non-blocking in a TCP stack (java)

Question

I have a question about a connect() call of a TCP socket implementation. What does it mean for a connect() call to be non-blocking. The connect() call does a three-way handshake with some other socket, by sending a syn, waiting for a SYNACK and then send an ACK. The connect() call also returns true if the connection succeeded or false if it did not succeed.

If the call is non-blocking then I guess that means that the connect should return immediately, even if it is still waiting for a SYNACK, but in that case it can never return false when it fails to connect because by then it already returned.

So my questions: - What does it mean for a connect() call to be non-blocking. - How does a connect() call achieve this? Is this only possible using threads? - Im simulating a tcp stack in java, could you give a simplified example of how the non-blocking version would look? I included a sketch of what I think the blocking version roughly looks like (more psuedo code than actual java):

public boolean connect(IpAddress dst, int port){
    // create a syn packet and send it
    ipLayer.send(.....,<synpacket>);
    try{
        // wait for a synack and store it in receive_packet
        ipLayer.receive(...., receivePacket,<timeout>);
    } catch( TimeoutException e ){
        // timed out.
        return false;
    }
    // use information from a receivePacket to create an ack-packet then send it.
    ipLayer.send(<ackpacket>);
    return true;
}

Answer 1

So my questions: - What does it mean for a connect() call to be non-blocking.

Exactly what you said. It does not wait for network traffic.

How does a connect() call achieve this? Is this only possible using threads?

If you define threads broadly enough, then the answer is yes. But typically it's not implemented with what we normally consider threads. It just tells the network stack to make the connection. The network stack sends out packets and respond to things like timer and network interrupts to keep the process going.

Im simulating a tcp stack in java, could you give a simplified example of how the non-blocking version would look? I included a sketch of what I think the blocking version roughly looks like (more psuedo code than actual java):

Just don't wait for a reply. Determine if it's possible to send a SYN. If not, return an error. If so, send the SYN. If you need a thread to wait for the reply for some reason, then you'll have to create a thread to do that.

But something about your code is fundamentally broken. You either need a thread in both the non-blocking case and the blocking case or neither. It's impossible to need a thread in one and not the other. If you need a thread in the non-blocking case, it's only because you can't run your TCP engine without a thread. But then if you don't have one in the blocking case, there's no way to run your TCP engine. What happens when the other side sends packets? Say the other side sends a RST -- how will your code reply to it?

Answer 2

You need to look at the actual Java API. A non-blocking connect consists of two operations: a connect(), which sends the SYN and initiates the handshake, and a finishConnect(), which tests for completion of the handshake. The handshake is asynchronous, and when it completes it triggers an OP_CONNECT for the Selector.

There is no 'return false' from any connect operation in Java, but there are exceptions.