Re: Sockets

>Hi,
>
>I am using winsockets on eVC4, and I was reading the documentation, where it
>said:
>"Successfully completing a call to send does not confirm that data was
>successfully delivered."
>
>So is there a way for me to know if the data was successfully sent, without
>having to send data and wait that the receiver sends back a confirmation.
>
>Thanks
>
>Filipe Madureira

If you look at how TCP works, you discover that having your remote
application send some kind of ACK back would not cost more performance
wise if you really NEED the confirmation before your application moves
on.

Under TCP, the send call will not even guarantee that the data is
physically sent out imediately. Well, it will be surely sent out if
you send a full, hence complete segment. However, if you send fewer
data the Nagle algorythm may kicks in which tries to colletct multiple
small data elements into a single segment to keep performance
bottlencks down to the minimum in cases where lot's of small data
elements otherwise would be sent out in a short period of time. The
classicle case of such a scenario would be a telnet session where
initially every single keystroke would be sent out. So, in this
scenario if you type fast enough TCP automatically will collect single
keystrokes into a single segment. The very same thing happens to your
application if say you send "command1" mostly immediatelly followed by
"command2".

The oponent - once it will get your segment will send an ACK back to
you anyways. If memory serves the standard requieres the oponent to
ack every second segment or send an ack no later than after 200ms
which ever comes first. So, if the application before this happens
sends some application ACK'ing data said data will be happily carried
back to your application in the same segment.

As a result, you either don't really care for an immediate response in
favour of optimal throughput by leaving optimisations to the TCP
layer, or else you must change your application specific protocol to
include a reply.

HTH

Markus
.

Relevant Pages

  • Re: TCP SACK issue, hung connection, tcpdump included
    ... because the segment which never gets correctly ACKed is also the ... SACK block is DSACK information telling explicitly the address ... if this ACK doesn't reach the ... SERVER TCP, RTO is triggered and the first not yet cumulatively ACKed ...
    (Linux-Kernel)
  • Re: congestion control, Netware 5.1 <-> IRIX 6.5
    ... Is a 'segment' what you ... get after reassembly of all fragments carried in individual packets? ... more packets from Novell right after it gets the ACK ... I am not sure why the tcpdump 'bad tcp checksum' are occuring. ...
    (comp.sys.sgi.misc)
  • Re: TCP and syncache question
    ... syncache_expandreturns 0 and tcp_input drops the segment and sets a reset. ... It seems to me that such a wrong segment should be interpreted as to be from another connection and as such the segment should be ignored. ... When the correct ACK comes, the connection could still be established. ... the establishment of incoming connections can seriously be disturbed by someone sending fake ACK packets. ...
    (freebsd-net)
  • Re: TCP and syncache question
    ... syncache_expandreturns 0 and tcp_input drops the segment and sets a reset. ... But syncache_expandalso deletes the syncache entry, ... It seems to me that such a wrong segment should be interpreted as to be from another connection and as such the segment should be ignored. ... When the correct ACK comes, the connection could still be established. ...
    (freebsd-net)
  • Linux TCP - unexpected retransmissions
    ... small messages using TCP. ... This latency occurs randomly ... time (segment 5 and 6 below), for unknown reasons, the second TCP does ... three instances of a retransmission. ...
    (comp.os.linux.networking)