From Newsgroup: alt.os.linux
On Tue, 9/9/2025 6:54 AM, Daniel70 wrote:
On 9/09/2025 1:20 am, R.Wieser wrote:
Daniel,
But how does the distant end know when I have received the entire file >>>>> (i.e. Download end time)??
As said, the sending-side marks the last to-be-send data-block as being ... >> well, the last block. :-)
Similarly, how does the distant end know when my computer started the >>>>> Upload (Upload start time)??
By receiving the first block of data ?
Mind you, files do *not* get send as a single block, but as a number of
smaller blocks.
Regards,
Rudy Wieser
Yes, understood, Rudy, don't start sending second Block until reception of first block acknowledged.
Install a copy of Wireshark, watch the data packets and
the <ACK> for the data packets in flight. That will back
up what someone is telling you about sliding windows
and pipelined Internet transfers.
You could enable Wireshark, before a speedtest.net run
and record the activity. Wireshark taps the NIC for the
packets, so packets leaving the machine can be recorded.
Wireshark has things like "dissectors", which can
summarize conversations between computers. As an
additional diversion when watching two computers
talk to each other. For example, the file sharing
between two computers, there is a dissector for that,
but it doesn't go deeply enough into the "reasons"
field on a failure. I think one file sharing I tried
to debug that way, it told me the server side
reported "Need more information", which isn't all
that helpful.
*******
If we waited for <ACK> as you propose, your Internet
speed would be 5KB/sec. We got to witness this at work,
when doing remote access to work from our homes, and
our server had a slight technical issue. And what
was happening there essentially, was "waiting for
<ACK> before next packet sent". And we were getting
5KB/sec performance on ADSL or a cable links.
That is what a link latency can do, to an un-pipelined
transfer.
If you want to study a controlled transfer, you can use
ttcp. On Windows, this was pcattcp.exe back in the day.
That should send a burst of packets to a receiver node,
and the receiver node running pcattcp sends <ACK> back
towards the sender. Then your Wireshark trace is easier
to read.
https://en.wikipedia.org/wiki/Ttcp
What I have on disk is:
Name: PCATTCP-0114.zip
Size: 121336 bytes (118 KiB)
SHA256: 76A50D5F19560616E1FE1805E2BBF8F223469BDE5F80F326138DBFC95A1B8CFA
and there is an EXE in the ZIP, as well as some source code.
https://web.archive.org/web/20151208023554/http://www.pcausa.com/Utilities/pcattcp/PCATTCP-0114.zip
(
https://web.archive.org/web/20151231101810/http://www.pcausa.com/Utilities/pcattcp.htm )
The following is just a test I can run on one machine,
using one invocation of the program as a receiver,
and another invocation as the transmitter. The
127.0.0.1 address is just an IPV4 loopback address.
You can also run this between two computers, and then
the packets go through the Ethernet interface (or whatever).
You would use "ipconfig" on the receiver machine, so you
know what address to use on the transmitter.
.\pcattcp -r -c # Start a receiver in one window.
PCAUSA Test TCP Utility V2.01.01.14 (IPv4/IPv6)
IP Version : IPv4
Started TCP Receive Test 0...
TCP Receive Test
Local Host : WALLACE
**************
Listening...: On TCPv4 0.0.0.0:5001
Accept : TCPv4 0.0.0.0:5001 <- 127.0.0.1:63503
Buffer Size : 8192; Alignment: 16384/0
Receive Mode: Sinking (discarding) Data
Statistics : TCPv4 0.0.0.0:5001 <- 127.0.0.1:63503
16777216 bytes in 0.022 real seconds = 744727.27 KB/sec +++
numCalls: 2049; msec/call: 0.011; calls/sec: 93136.364
.\pcattcp -t 127.0.0.1 # Transmit to that receiver, in another window
PCAUSA Test TCP Utility V2.01.01.14 (IPv4/IPv6)
IP Version : IPv4
Started TCP Transmit Test 0...
TCP Transmit Test
Transmit : TCPv4 0.0.0.0 -> 127.0.0.1:5001
Buffer Size : 8192; Alignment: 16384/0
TCP_NODELAY : DISABLED (0)
Connect : Connected to 127.0.0.1:5001
Send Mode : Send Pattern; Number of Buffers: 2048
Statistics : TCPv4 0.0.0.0 -> 127.0.0.1:5001
16777216 bytes in 0.023 real seconds = 712496.52 KB/sec +++
numCalls: 2048; msec/call: 0.011; calls/sec: 89062.065
That's a loopback test, which was done on just one computer
to illustrate the concept. If I did it with
two computers, and had Wireshark running at the
transmitter, I should be able to see pipelined transfer.
*******
You can find copies of Volume 1 of Stevens "TCP/IP Illustrated",
which can give you things like protocol diagrams for popular
protocols. Somewhere in there, you might find "slow start"
and other related TCP/IP topics. 1089 pages.
http://www.r-5.org/files/books/computers/internals/net/Richard_Stevens-TCP-IP_Illustrated-EN.pdf
The first volume is usually enough for casual knowledge seeking.
It's a pretty big hard cover book normally, big enough
to use as a door stop. The three volume set, that door is
never going to move :-)
Paul
--- Synchronet 3.21a-Linux NewsLink 1.2