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?