TCP Half Opens ?

This is a discussion on TCP Half Opens ? within the Networking/Device Communication forums, part of the General Programming Boards category; Happy new year to all !!! Similar to the concept of TCP half close states, why can't we have a ...

  1. #1
    Arron
    Join Date
    Jul 2005
    Posts
    17

    TCP Half Opens ?

    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

  2. #2
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,265
    If a door is half closed, isn't it also half open? The same concept goes for TCP connections.

  3. #3
    Arron
    Join Date
    Jul 2005
    Posts
    17
    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
    Last edited by arron; 01-04-2006 at 12:08 AM.

  4. #4
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,265
    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.

  5. #5
    Arron
    Join Date
    Jul 2005
    Posts
    17
    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.

  6. #6
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,265
    Is there any drawbacks for this feature.
    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....

    so that the application can choose whether to go for 3 way handshake or half open connectionadd this "half-open" feature
    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

  7. #7
    Pursuing knowledge confuted's Avatar
    Join Date
    Jun 2002
    Posts
    1,916
    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.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. TCP Header problem (error)
    By nasim751 in forum C Programming
    Replies: 1
    Last Post: 04-25-2008, 08:30 AM
  2. Accessing TCP flags in TCP packets on Linux using C !!
    By vishamr in forum Linux Programming
    Replies: 2
    Last Post: 10-16-2006, 09:48 AM
  3. passive opens
    By kryptkat in forum Networking/Device Communication
    Replies: 1
    Last Post: 05-14-2006, 11:19 PM
  4. Half life Problem which I am right and the teacher is wrong
    By Shadow12345 in forum A Brief History of Cprogramming.com
    Replies: 13
    Last Post: 11-06-2002, 04:28 PM
  5. The glass is half full
    By dirkduck in forum A Brief History of Cprogramming.com
    Replies: 11
    Last Post: 03-30-2002, 03:08 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21