Failing sendto/send transmit complete datagram/packet anyway? - TCP-IP

This is a discussion on Failing sendto/send transmit complete datagram/packet anyway? - TCP-IP ; I ran some test with UDP sendto() and TCP send() under heavy traffic. All tests with Winsock 2.2 on Windows Vista, all sockets non- blocking. I noticed that when sendto/send fail with error code WSAENOBUFS (insufficient buffer space or full ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Failing sendto/send transmit complete datagram/packet anyway?

  1. Failing sendto/send transmit complete datagram/packet anyway?

    I ran some test with UDP sendto() and TCP send() under heavy traffic.
    All tests with Winsock 2.2 on Windows Vista, all sockets non-
    blocking.

    I noticed that when sendto/send fail with error code WSAENOBUFS
    (insufficient buffer space or full queue), or WSAEWOULDBLOCK
    (non-blocking socket operation could not be completed immediately)
    then the corresponding datagram or socket are transmitted anyway
    and the remote client receives them anyway.


    Is it expected?


    I assumed sendto/send failing with return value < 0 and any
    error code do not send any data.


  2. Re: Failing sendto/send transmit complete datagram/packet anyway?

    On Jun 13, 2:37 pm, "mar...@hotmail.com" wrote:

    > I noticed that when sendto/send fail with error code WSAENOBUFS
    > (insufficient buffer space or full queue), or WSAEWOULDBLOCK
    > (non-blocking socket operation could not be completed immediately)
    > then the corresponding datagram or socket are transmitted anyway
    > and the remote client receives them anyway.


    How did you verify that the very datagram that failed is the one you
    actually received? (There are many ways you could have done this, some
    valid and some flawed. For example, any based on counting packets or
    datagrams received is flawed.)

    > Is it expected?


    No.

    > I assumed sendto/send failing with return value < 0 and any
    > error code do not send any data.


    That is what I too would expect.

    DS


  3. Re: Failing sendto/send transmit complete datagram/packet anyway?

    On Jun 20, 6:49 am, David Schwartz wrote:
    > On Jun 13, 2:37 pm, "mar...@hotmail.com" wrote:
    >
    > > I noticed that when sendto/send fail with error code WSAENOBUFS
    > > (insufficient buffer space or full queue), or WSAEWOULDBLOCK
    > > (non-blocking socket operation could not be completed immediately)
    > > then the corresponding datagram or socket are transmitted anyway
    > > and the remote client receives them anyway.

    >
    > How did you verify that the very datagram that failed is the one you
    > actually received? (There are many ways you could have done this, some
    > valid and some flawed. For example, any based on counting packets or
    > datagrams received is flawed.)
    >


    I included a sequence number (32-bit size) in every datagram or
    packet. Then I
    logged each failing sendto/send and its sequence number. Then the
    receiving client checked all sequence numbers to make sure
    a new datagram/packet does not include a sequence allready received
    All such cases matched the sequence numbers from failing sendto/send.




    > > Is it expected?

    >
    > No.
    >
    > > I assumed sendto/send failing with return value < 0 and any
    > > error code do not send any data.

    >
    > That is what I too would expect.
    >
    > DS




  4. Re: Failing sendto/send transmit complete datagram/packet anyway?

    On Jun 20, 11:44 am, "mar...@hotmail.com" wrote:
    > On Jun 20, 6:49 am, David Schwartz wrote:
    >
    > > On Jun 13, 2:37 pm, "mar...@hotmail.com" wrote:

    >
    > > > I noticed that when sendto/send fail with error code WSAENOBUFS
    > > > (insufficient buffer space or full queue), or WSAEWOULDBLOCK
    > > > (non-blocking socket operation could not be completed immediately)
    > > > then the corresponding datagram or socket are transmitted anyway
    > > > and the remote client receives them anyway.

    >
    > > How did you verify that the very datagram that failed is the one you
    > > actually received? (There are many ways you could have done this, some
    > > valid and some flawed. For example, any based on counting packets or
    > > datagrams received is flawed.)

    >
    > I included a sequence number (32-bit size) in every datagram or
    > packet. Then I
    > logged each failing sendto/send and its sequence number. Then the
    > receiving client checked all sequence numbers to make sure
    > a new datagram/packet does not include a sequence allready received
    > All such cases matched the sequence numbers from failing sendto/send.
    >


    I was not clear here. I ran two cases. In the first case, the sender
    was resending
    the datagram/packet after its sendto/send failed and this is when
    the client
    saw a duplicate sequence number that matched the one from the
    failing sendto/send.

    In the second case, the sender did *not* re-send the datagram/packet
    and the client
    did not see any duplicate sequence numbers.



  5. Re: Failing sendto/send transmit complete datagram/packet anyway?

    On Jun 20, 11:21 am, "mar...@hotmail.com" wrote:

    > I was not clear here. I ran two cases. In the first case, the sender
    > was resending
    > the datagram/packet after its sendto/send failed and this is when
    > the client
    > saw a duplicate sequence number that matched the one from the
    > failing sendto/send.


    That isn't complete proof. The second packet could simply have been
    received twice.

    > In the second case, the sender did *not* re-send the datagram/packet
    > and the client
    > did not see any duplicate sequence numbers.


    That sounds like complete proof. You are absolutely positive you
    incremented the sequence number even when the send failed?

    DS


  6. Re: Failing sendto/send transmit complete datagram/packet anyway?

    On Jun 20, 2:32 pm, David Schwartz wrote:
    > On Jun 20, 11:21 am, "mar...@hotmail.com" wrote:
    >
    > > I was not clear here. I ran two cases. In the first case, the sender
    > > was resending
    > > the datagram/packet after its sendto/send failed and this is when
    > > the client
    > > saw a duplicate sequence number that matched the one from the
    > > failing sendto/send.

    >
    > That isn't complete proof. The second packet could simply have been
    > received twice.
    >
    > > In the second case, the sender did *not* re-send the datagram/packet
    > > and the client
    > > did not see any duplicate sequence numbers.

    >
    > That sounds like complete proof. You are absolutely positive you
    > incremented the sequence number even when the send failed?
    >
    > DS


    I will have to look at that code later with fresh eyes. I like to
    take
    a break from one code and move to another, then resume the old
    code. Better when done in cycles, a few weeks apart.




+ Reply to Thread