In message <0056900014977107000002L072*@MHS>, [email protected] writes:
>1.
>People claim that TCP semantics is not violated if TCP acks are "spoofed", as
>long as the initial 3-way handshake and the FIN are respected.
>Seems strange to me. Namely, the sending TCP will have lost the data because o
>f spoofing and falsely assumes it has arrived if the link breaks down, i.e. t
>here is a "false positive". Who says the sender wants to do a FIN, it could j
>ust stop and will
>notice nothing about the break down.
You're right, spoofing ACKs does violate TCP semantics. Some folks argue
that if their intermediate node, that spoofs ACKs, also buffers data then
you're safe, but they're wrong -- as the intermediate could fail.
>2.
>What if I used large windows, but spoofed the initial SYN/ACK, i.e. the opposi
>te. This will speed up small transfers, because there is no wait for the hand
>shake to complete. The other side can not open the socket, the first data tra
>nsfer will simply
>fail, so no false positives here? Good idea or not?
Well it doesn't violate semantics in the same way -- if the other end does
not open the connection then either (a) you'll get a RST and the connection
will fail or (b) you'll retransmit several times and the connection will
fail. It will never claim that data is delivered that was not.
>3.
>What guarantee does an application have anyway. If I do a send in TCP, the dat
>a goes into TCP's buffer without error and is handled asynchronously, which c
>ould fail. How rock-solid is end-to-end reliability?
If you linger on the close (such that all data is acknowledged before your
socket closes -- and assuming no ack spoofing) then you'll have a firm
guarantee that your data reached the remote system. This guarantee, however,
is only for the end system -- it does not say the end application received
the data (it may never read it).
Craig
This archive was generated by hypermail 2b29 : Mon Jan 08 2001 - 11:08:06 EST