AFAICR: When you receive SYN/ACK, you go to open. If all you get is a SYN, you go to SYN-RECVD. If two ends try to connect simultaneously, a good implementation will recognize this, and switch over to "simultaneous open" mode, so both will receive SYNs, both will send SYN/ACKs, but only one connection would be established, not two.

still there must be some timeout some where where one side just goes in to the open state. Because if one side goes in to the open state the other side will no longer be sent any sync-ack's from the open side.....

No, there is no timeout.

The sending side will keep sending SYN while it's wanting to open. The receiving side will respond with a SYN/ACK when it gets a SYN. The opening end will then (eventually) send an ACK. If the opening side doesn't get the SYN/ACK, it will re-send the SYN, which will re-send the SYN/ACK.

There is a timeout where the SYN/ACK state object may tear down (and fail the opening) if it never gets an ACK. This timeout was very long, which was the original source of the "teardrop" SYN flood attack.

IAICR, if the ack gets dropped, the next piece of data sent from the opening client will serve as the ACK instead. Thus, if you open a connection, but then want to send nothing for a very long time, the connection may be broken, but you won't find out about it until you try to send (because the other end timed out in SYN/ACK state and tore down the connection). That's the semantic of TCP in general, though -- you're not guaranteed to know when the other end spontaneously combusts.

This may be a little late, but have you checked out the reliable UDP protocol presented in Game Programming Gems 5? I'm in the process of implementing it, and i'm hopeful that it will be very effective and efficient. Its a good article, you should pick up the book if you don't already have it and give it a read.