uncertainty in tcp data arrival?

This is a discussion on uncertainty in tcp data arrival? within the Networking/Device Communication forums, part of the General Programming Boards category; i have been fidgeting with winsock tcp ( i created simple client and server applications with only a main function ...

  1. #1
    Registered User
    Join Date
    Jan 2009
    Posts
    28

    Exclamation uncertainty in tcp data arrival?

    i have been fidgeting with winsock tcp ( i created simple client and server applications with only a main function )

    (i know this isn't the code but i'm trying to get the idea across i can post code if necessary)

    server
    Code:
    accept
    recv ( 17 bytes )
    shutdown          // listning and connected socket
    closesocket       // listning and connected socket
    exit application
    client
    Code:
    connect
    send ( 17 bytes )
    Sleep( 5000 )
    send ( 17 bytes )
    shutdown
    closesocket
    exit application
    i started the server and then started the client. ( i'm using blocking sockets )
    so basicly what i tried to do was:

    - make the server wait for a connection
    - recieve the 17 bytes sent by the client
    - and exit the server application ( closing the sockets properly )

    - see the error on the client side on the second attempt to send 17 bytes

    i was suprised to see that the second attemp to send returned 17 bytes ( expected a SOCKET_ERROR ) eventhough the server application was no longer running. of course i'm a bit disturbed. can someone explain what's happening?
    Last edited by symbiote; 04-21-2009 at 05:15 AM.

  2. #2
    Registered User
    Join Date
    Mar 2009
    Posts
    12
    I have seen something like this when I was programming with UDP sockets. Just a "shot in the dark" what does errno report?

    BTW, I'm mostly a linux programmer, so this might not be of help.

  3. #3
    Registered User
    Join Date
    Jan 2009
    Posts
    28
    hi trinli,

    a call to WSAGetLastError() which retrieves the winsock error returns 0
    ( this should mean, no error if i remember )

    i guess i could have expected that since send did not return -1 (SOCKET_ERROR)

  4. #4
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,246
    The TCP socket layer is "optimistic" in that it reports success if the packet physically left your host or was queued for sending during packet coalesce. It just happens that at the moment you send the next 17 bytes, the server side has shut down. It should respond to the client packet with a TCP reset.

    But in the meantime, your socket layer happily continues along. It won't be until after you receive the RST, and after you attempt yet AGAIN to send a packet, that you will see the error condition.

    All is normal...
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  5. #5
    Registered User
    Join Date
    Jan 2009
    Posts
    28
    hi brewbuck,

    as you mentioned, a third attemp by the client gave an error ( 10053 - WSAECONNABORTED )

    how am i supposed to know have figured out that the second attemp failed? ( adding acknowledgements in my data would seem redundant since tcp is already supposed to handle this )

  6. #6
    Registered User
    Join Date
    Jan 2009
    Posts
    28
    hmm the tcp socket layer is telling me that my data got through when it didn't.
    the recieving application had already closed the connection and even exitted (properly).

    - how is everything normal/optimistic? ( it sounds like i'm being lied to by the socket layer )
    - why am i not given an error on the first send attempt after it knows the connection has already shutdown?
    - what is the normal way to detect this problem?

    i'm still stuck on this problem guys

    please help

  7. #7
    tjb
    tjb is offline
    Registered User
    Join Date
    Jan 2009
    Posts
    31
    I think it might work better to have a bidirectional protocol. In that case, it would happen something like:

    >>> send quit command.
    <<< receive quit acknowledgment.

    Wait 5 seconds.
    >>> send quit command.
    <<< receive gives error, WSAEDISCON or other error.

    WSAEDISCON only happens during recv, I believe.

  8. #8
    Registered User
    Join Date
    Jan 2009
    Posts
    28
    thanks for all the suggestions. i thought i'd close the topic properly because i already resolved this a while ago.

    the problem was that i didn't understand the tcp shutdown sequence. i was slamming the connection shut by calling shutdown with the SD_BOTH flag. i didn't realize that both sides have to to agree that the connection is shut instead of one side suddenly sending RST packets.

    so i'm calling shutdown with the SD_SEND flag instead now so that each sender shuts down their own sending. everything is working fine now ( no socket erros ). i guess the uncertainty was caused by me not shutting down properly.

    this page's micro faq confirmed it
    Winsock Programmer's FAQ: Debugging TCP/IP

    Greeting,
    symbiote
    Last edited by symbiote; 05-23-2009 at 04:44 PM.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. brace-enclosed error
    By jdc18 in forum C++ Programming
    Replies: 53
    Last Post: 05-03-2007, 05:49 PM
  2. Binary Tree, couple questions
    By scoobasean in forum C Programming
    Replies: 3
    Last Post: 03-12-2005, 08:09 PM
  3. binary tree of processes
    By gregulator in forum C Programming
    Replies: 1
    Last Post: 02-27-2005, 11:59 PM
  4. All u wanted to know about data types&more
    By SAMSAM in forum Windows Programming
    Replies: 6
    Last Post: 03-11-2003, 02:22 PM
  5. Replies: 1
    Last Post: 07-31-2002, 11:35 AM

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