arron

Happy new year to all !!!

Similar to the concept of TCP half close states, why can't we have a concept of TCP half opens ??

Please let me know your valuable comments & ideas


/arron

bithub

If a door is half closed, isn't it also half open? The same concept goes for TCP connections.

arron

Hi bithub,

well i'll clarify what i asked ...
After 3 way handshake, Host A & B, carry on with data transfers and down the line Host A send a FIN. But it can still accept incomming data. This is half-close.

Consider this scenario:

Host A only needs incomming data from Host B.ie,.he's not doing any send(), only recv().
so in this case can't we think of a " Half-Open" scenario.
rather going for 3 way handshake,
Host B sends a SIN, Host A ACK's that and then can't they proceed with the data trasfer.

So iam asking in scenarios like this rather going for a 3 way handshake can't we have somethin like this ?
This is a new design which came to me, so just wanna know any drawbacks/advantages in this design ?


/arron

bithub

That wont work. If host B doesn't send an ACK after A sends the SYN/ACK, then A will never consider the TCP connection completed, and it will drop all other packets it receives from B. If Host A only needs to receive data, then it needs to send a FIN packet after the 3 way handshake (This is the normal half-closed state). Basically, you can't get around the 3 way handshake. There is no way the server will allow the client to send it data without it acknowledging its SYN first.

arron

You are talking about the existing feature of TCP ( 3 way handshake).

I completely agree to that. But what i asked was , And is it possible to add one more option to this TCP ie., Half open , so that the application can choose whether to go for 3 way handshake or half open connectionadd this "half-open" feature. And how is this feature all about ?

Is there any drawbacks for this feature.

bithub

Well the main drawback is that you would no longer be using TCP. You would be using a custom protocol that would require changes to everyone's TCP implementation to use it.

The other main problem is that with your two-way handshake, what happens when the server's ACK is lost? The client will continue to wait for the ACK, but the server will now wait for data transfer (since the server no long requires the last ACK from the client). The server won't time out until the keep-alive timeout is reached. Even if you ignore the fact that packets get lost, you run into another problem....

How can an application make this choice? Applications do not get direct access to the TCP/IP stack, they rely on socket library functions. In order for this to happen, you would not only have to rewite the TCP implementation, but you would have to make additions to the socket library implementation as well. On linux you could do this by modifying the kernel source, but I'm not sure how you would do this on Windows (I don't think a filter driver would do the trick here, you would probably have to write your own transport driver).

There's also the possibility that it would be easier for a malicious host to spoof an IP address, but I'm too tired to think that one through

confuted

I think what you're looking for is something along the lines of the UDP protocol. TCP is a handshaking protocol by definition, and there is no way around that. UDP, however, is a "send it and forget it" protocol - once host B sends a packet to host A, it assumes that the packet was received and sends the next one. Search on Google for more info.

__________________
Away.