I'm working on writing a torrent client from scratch in GoLang, partially as I've always found the BitTorrent protocol to be interesting and wanted to learn more about it, and also because I wanted to improve my understanding of networking.

As I've continued the implementation, I've gotten to a point where I am able to successfully download files, not always reliably, but enough of the time where I'm just working on improving the code. A lot of the messages that I'll get from peers in the swarm will end up being messages with "bad" ids, meaning that either the peer's client is wrong, or I have messed up my implementation somewhere. Thinking about the possibilities led me to the question: if I open up a TCP connection with a peer, but there happens to be some delay in my Read calls on the connection, is there a possibility that some of the data will be lost and I'll just start reading once I make the read call? Or is some of the data stored in some sort of buffer?

CodePudding user response：

Read on a TCP connection returns data in the sequence written by the peer until EOF or the connection fails.

Read on a TCP connection never skips over data in the stream.

CodePudding user response：

Your answer is probably OS-dependent (thinking is setsockopt / posix).

The best way to confirm is to write a small program that reads with a certain delay and inspect with wireshark the network flow. And inspect the code of net package (it is open source)

TCP has control flow, if you don’t read, the other part will block the sending of data.

However we transmit packets of data with variable window (in bytes).

If you read ond byte per time, you should be able to read the packet received until the end. With any delay.

Yes the data received is in OS buffer.